That is until the time comes where a new project is being started or requirements are being updated. Usually then some sort of “rivalry” will ensue, and in 90% of the cases it will be between a designer or information architect and a developer or development coordinator. Scope was not fully explained or defined, the design is too complicated to build, or data is not coming from the sources it was meant to.

In those times frustration can quickly result in stress and lack of commitment to a project. Let’s see what we would do to remedy that…

1) Information Architects: Start off on the right foot and plan ahead

At the beginning of a project make sure that you define scope and requirements clearly. Nothing is worse than a badly set up and planned out sitemap or wireframe without annotations or data specifications. To create a clearer mindset it is always best to let a lead developer for the project to have a look at the sitemap/wireframe before it goes to the client to ensure all requirements are met, what the developers will need to consider and where data needs to come from. It is also good practise to let developers come up with a timeframe of how long the development will take based on the wireframe.

2) Designers: Plan your designs

This is very self-explanatory, but you would not believe how many designers (especially freelancers I worked with) are getting it wrong: make sure you understand the intention of the site and its requirements. A simple brochure-style site has and entirely different look from a travel booking website or an online shopping website.Make sure you look at the sitemap and wireframe and if unsure about functionality or what development tricks (AJAX, Flash, JS) will be used then ask questions!

3) Designers: Form follows function – or: practical design

Websites are here to wow us – but will a Flash and graphics heavy website really do the trick when all a user wants to do is log in and find out if his holiday booking went through? A stunning design is great, but you also need to take the purpose of the site, its users and their habits or actions while on the site into consideration. Visitors or users of the website need to feel comfortable being and interacting with the website.

Additionally, avoid Flash-heavy pages or content: aside from not everyone being on fast broadband, Flash intros are a thing of the past, and Flash content still cannot be indexed properly and disallows users from bookmarking important or relevant pages properly.

4) Information Architects / Designers: Understand the tools of the trade

Keep bookmarks for development tools handy!

While you may not do any hands-on coding it makes sense to at least understand what certain development tools, what their limitations are, and most of all what other developers manage to do with them. Brush up on developer tools such as AJAX, MooTools, jQuery, CSS, Flash and xml-integration. Keep a list of development bookmarks not only for that reason, but also to then find a solution together with the development team to make a certain effect or part of functionality working – and it gives you a good idea what other developers are doing to stay on the forefront of development techniques.

5) Designers: define interaction

Following on from the previous point, make sure and be clear about how certain tools are going to be used on the site. More and more opportunities arise where certain functionality can be used, interactive login-panels, auto-updating shopping baskets, interactive flight-checks, Flash-driven maps… anything is possible! But make sure you understand that these interactive development stages can take up a lot of time, so it is best to check with the project manager / development leader to see how much of the budget has been alloted to this stage and if you may need to cut back for this phase.

6) Designers: define and share responsibilities

For a designer a project is not finished once the PSDs are sent to the development team – be sure to stick your nose into the development process occasionally to make sure your designs are implemented correctly and that they developers have all they need. It may be that you need to rethink / redesign certain panels or call to actions or that you will need to resupply certain pages, panels or button styles.

Following on from point #4, it might even make sense helping at the CSS / HTML cutup to not only help the developers, but to get an understanding how your design is looked at and what needs to be done. Knowing CSS / HTML cutup (even in parts) is a really valuable asset these days!

7) Information Architects: capture information, the right way!

The buzz-word for years is “data-capture” – getting visitors to a website is one thing, but making sure they come back and leave their details is another. Make sure your forms are easy to understand and not pages and pages long if you don’t want to scare them away, and only ask for data necessary to the task – why should I give you my date of birth or post code if all I want is a newsletter??

Also, do make sure you have a tick box to opt in and out of marketing materials such as direct mail or newsletters, and have a clear call to action to your privacy policy.

.

I hope the tips help keep you and the development team working successfully on all your projects!

Last time I wrote about this Yahoo / Flash mashup I connected the Yahoo map’s API through Flash and PHP to a MySQL database and was able to write / read from the entries. My next goals were to integrate a user-login, adding links, implementing moderation and a Flash image uploader script.
.

Integrating a PHP uploader script

A very important aspect for both users (and our clients) is to be able to ‘take part’ and ‘be part’ of shaping the user-generated content area of a site, to leave their mark. Naturally, images and content are the weapons of choice, as such the next step was to work on an image-uploader. The task:

Develop an image uploader script through Flash that would allow users to upload an image from their desktop, store it online in a writeable folder on the server and reference to it from the SQL database and display the image for the relevant post for the relevant user.

This wasn’t such an easy task. I had a good look around how Flash tutorial websites I usually frequent handle image upload. After some working I managed to get the PHP side of things working – which also had its own issues to start with, it would not update file names properly (see image to the right, click to enlarge)! After some fiddling around I managed to get the php script to work, and if you like you can download it here:

Please download the file here: fileupload.zip (~800 bytes)

What the script does is it defines the maximum file dimensions (180×300 max in either direction) and uploads the file to a temporary directory (/tempstore/) before giving it a timestamp and name-change and putting it into the /images/ directory.

.

Connecting PHP with Flash

This was a bit (okay, a hell of a lot) more complicated: through the variables ‘FileReference‘ and ‘browseListener‘ and a couple of other event listeners I managed to tell Flash how to use the “Browse…” button and how to handle the uploaded image. At the moment the Flash file uploads the image to the database correctly, but it will break if the image does not have the correct size, so I need to work on getting the image-resizer to work. Once that works I’ll upload the source as well.

.

Sneak Peak for the image-uploader (snapshot of 9th July 2008)

The main uploader:

.

The uploaded image and adding information:

.

…and the result:

.

Conclusion and next steps

Well, so far it is looking very promising with the image-uploader! Obviously we are still some way to go with it, but I think the project is starting to take shape! Integrating browse and upload functionality in Flash took some work, but thanks to ActionScript 2.0′s event listeners it worked out reasonably well and connected to the database. Obviously we are still taking about only one user at a time, so I would need to review the php code at a later date to also make sure there is a folder structure per user present, but that should not be too much of an issue. Watch out for the next entry on this mash-up, by then I will have the uploader finished and maybe add the ability to upload multiple images to show a slideshow, we will see!

.

Lastly, if you enjoyed the article – or just the flash map – then please leave a comment, I would really appreciate it, as it gives me always another boost to write more

What we would like is some sort of members-only application that allows our users to track their journeys with us and to maybe blog about them, but it should look swish and very easy to use. We would like a similar functionality for our travel guides who would then post information about the tours.

The idea of a blog is a great tool for customer retention, if done right it allows users to post comments about their journeys, maybe with images to keep a log of what they are doing while on that trip. It would allow visitors to see what is going on on a journey with <Company Name> and what you can do or what the user(s) saw and took part in. Obviously, I wanted to offer a little bit more than just a blog. My idea was to work on a map-blog…

(Please note, if you would just like to see the map in action, just scroll down to the bottom of this page)

.

Integrating with new technologies

For (flash) designers and developers there are a number of new technologies that give a user access to content and functionality that was not possible a year or two back. Let us take Google or Yahoo for example: developers are given access to a great and increasing number of technological toys to play with: application programming interfaces (APIs) to integrate content such as Flickr images and albums, mail, rss feeds or maps.

Anyone, from an individual to a development company, has access to these API components, and more and more people are using them to give their clients (or their portfolios) a WOW-factor.

.

Travel blog + map = travel journal

Looking at the possibilities our CMS at work has (remember, its is aspx / .net) there was quite a range of possibilities we could offer our client something for the money. The obvious would have been setting up blog-facilities based on either each tour or destinations, giving registered users who have participated in a tour to blog and comment about it (we would run the user’s access against their booking history to grant write-rights). We could also set up forums and sub-forums to allow users to add comments about trips or destinations.

However, travel blogs or forum posts can be a bit text-laden, and the interaction only consists of a user posting, others reading and (if they like) commenting on posts.

Some time ago we did some Google Earth integration to one of our clients’ website which allowed the client to plot out tours on Google Earth, to give the user the ability to ‘see’ the tour and where it is going and what is going on. The idea of combining a map with a travel blog kinda became obvious.

With both Google Maps and Yahoo Maps giving excellent access to and support for their APIs I wanted to work on integrating a mapping solution with our user and blog-database. In the end I went for Yahoo Maps simply because their development network had a tremendous amount of information and code-snippets to get started with.

.

Yahoo maps and ActionScript – (API) key to success?

Once the extension was downloaded and a API key registered I went on integrating the map into the workspace. Just import / drag the component into the stage. You can edit its size simply by entering a new width and height into the properties (by default on the bottom of the stage). Your next step will need to be to check out the parameters. The screenshot on the right (click to enlarge) shows you where you can find the API in Flash CS3 and what parameters you will need to change by default, such as API key, zoom factor or starting location (by default USA map).

Now that we have a working API-integration into flash I tackled the next step: integration of a server-database to read posted points as well as add points to it. (In this example I used PHP / MySQL as this blog is based on a PHP system). You need to set up a database via PHPMyAdmin for example. Here is a sql-database for you to have a look at and use:

Please download the file here: entries.zip

So, what do we have in this database now: We have an ID (unique value for each entry), lat and long, a date (for timestamping entries), a short info and a descritption. These are the fields I will be using for now.

.

Writing to and from the Database

The next steps are to read from and enter information to the database through PHP. A simple

$sql = “INSERT INTO entries (id, lat, lon, date, info, description) VALUES (”, ‘$lat’, ‘$lon’, ‘$date’, ‘$info’, ‘$description’)”;

for entering information should do the trick. Which it did. I am not going into very much detail here, as the project is very code-heavy, but if you are interested in knowing more please do not hesitate to get in touch with me.

.

The first travel journal test

Here is now a first map-test (please note that I have disabled entering notes at this stage):

.

Closing comments and future plans for this project

Getting the API to work was a bit tricky, and it took me a couple of hours to figure out what could be done and what didn’t when it came down to connecting to a database.

• User-access: At the moment any user can access the map, as such I will need to work on a login-based system, with each login having their own database table, and maybe a selector at the start to see whose trip journal you would like to visit. This should hopefully not be too difficult *touch wood*.
• Image and video-upload: I will need to write an image upload script that saves the images on the server in the user’s folder and give each one a unique ID just in case. I’ll have to also look into resizing options and video compression if we are not using youtube etc
• Linking: Users should be able to cross-link or link to products / posts / etc
• Moderation & Administration: …and ideally all of the above should be moderated and maintained
• Plus, I want this to work in Adobe AIR later on as well, so I will need to rewrite a bit of the code later!

Lastly, if you enjoyed the article – or just the flash map – then please leave a comment, I would really appreciate it, as it gives me always another boost to write more

[UPDATE: I have updated this project's progress here]

Following up on the previous article you may have some idea about if the mobile web is something for your company and your products. You have probably looked at your target audience by now, you know what users are going to look for on your website, how they find it, what information they read on your website that is related to the product, and you have a clear picture in your mind what content you want to promote for a mobile device user.

The question is now, how do you begin? What do you need to look out for, and what is a best-practise approach?

First off all, lets discuss the phone itself. More and more phones are coming out these days, but most of them share common functionality: colour-screen, wireless / wap capabilities, and input devices (such as stylus or keypad or even keyboard).

-

Screen sizes:

When looking at the mobile phone manufacturers’ websites we can read that the most common screen sizes are:
128×160
176×220
240×320
320×480
…with the latter belonging to Apple’s iPhone.

Looking at the graphic to the left (click to enlarge), you will notice already that there is a considerable difference between the sizes. Over the past year the World Wide Web Consortium (W3C) has been working on a Web Best Practices document for designing and developing mobile phones for the web. (I will be referring to this document a couple of times).

From that, we know that the recommended usable screen width is 120 pixels and the minimum amount of colours is 256.

(N.B. it is worth mentioning here that these are recommended sizes to reach the maximum number of mobile web users, obviously you can create a number of versions depending on the size of the screen, one for normal phones, one for iPhones for example, but I will get back to that later on)

-

Information Architecture for mobile phones

I try and pride myself in preparing the best practice Information Architecture for any of our clients’ websites, and it is even more important for mobile sites. Desktop computers have the advantage of a full keyboard, mouse, big screen, and different windows you can click through, close, or go back to. On a mobile phone with a screen resolution of 120 pixels there is a lot less to play with: you can display only a limited amount of content on there, with only a limited number of links, not to mention small imagery. Plus, unlike the desktop computer the internet connection is very, very slow. The more you click, the more you wait or (if you are not using wireless) pay. As such we will need to strip the website down as much as possible. We need to limit the amount of copy, the amount of links and of course imagery and find a healthy balance between content and navigation.

Looking at the graphic to the right, it makes sense to keep your content fairly short and to the point. The reason you are browsing from a mobile phone is because you are interested in some quick information, not a novel. Due to the nature of mobile phone and its browser it is also important to repeat the navigation at the bottom of the main content area. At this point you are used to the “scroll down” functionality of your phone, and you don’t want to change your grip on the phone just to go back up where you just came from. The navigation here should be containing links related to what you just read (if it was a product then a call to action to get in touch would be good) and related information (such as similar products in that field / area).

So now we have looked at what the sizes are and what good practises are in setting the content up. So how do we develop this?

-

Development for mobile phones – considerations

Compared to web development for desktop computers mobile web developers need to consider a couple of limitations to a mobile website:

• One column layouts only, try not to use floats
• Reduce and optimize your HTML and CSS markup, don’t overdose on <div>’s and <span>’s
• Limit the number of images (that includes background images and graphical headlines and tabs!)
• Try not to use Javascript or any dynamic effects used for mouse and keyboard use (such as hover effects or iframes)
• If you use images, make sure you use alt-tags

-

Development for mobile phones – XHTML

Next to HTML / CSS one of the most commonly used languages for mobile phones is XHTML-MP (eXtensible Hypertext Markup Language – Mobile Profile), a subset of XHTML Basic and HTML and is the predominant language for mobile phone development.

An example of XHTML-MP can be found in the graphic below (click to enlarge):

As you can see, it is fairly easy, isn’t it.

-

Development for mobile phones – Navigation

Because you are working with a very vertical browser you will need to rethink your website’s navigation and plan ahead for a vertical list navigation, ideally together with access keys (access keys are the number keys on the keypad of a mobile phone 1-9 and 0). See below for an example using list navigation and access keys (click to enlarge)

(NB: If you intend to link a telephone number within a page to automatically dial the number on the users phone just use this snippet:
<a href=”tel:+123456789”>+1 23456789</a>)

-

Development for mobile phones – Publishing the mobile web content

Okay, so you have created a very simple version of the website, using semantic markup language and have generated the content how you would like it to appear. It is time to set the website up.

It would be ideal to have a sub-domain or a folder for your domain such as m.websitename.co.uk or www.websitename.co.uk/mobile and get users to go there directly using their mobile device. Another option would be to let the website detect the user agent similar to what you would do to use special style sheets for IE5/6/7 for example, in this case a
<link rel=”stylesheet” type=”text/css” media=”handheld” href=”mobile.css” />
will work wonders.

-

Testing

So the mobile version of your website is done, and you have sorted all your styles out and are ready to go live. Time to begin testing.
I would strongly suggest following this testing guide to ensure that everything goes well:

1. Desktop testing: Both Opera and FireFox have the great option for small-screen view. Test both without scripts (such as Javascript) and without graphics. Test without mouse
2. Emulator testing: Use any (or ALL) of the following emulators:
   Nokia’s emulator
   OperaMini simulator
   Blackberry simulator
   Openwave simulator
   Ready.mobi site-checker
3. Device testing: Get hold of many different mobile phones and test your website. Best option would be to test the site with mobile phones using WiFi in your own network, and once you are satisfied with the outcome go and try phones that do not have WiFi-capabilities (meaning you have to pay for each minute or kb) and test parts of the site.
4. Usability testing: knowing that the website works on mobile phones does not mean that it is usable. Test each aspect of the site, does it make sense? Can you find your way around it? Does your colleague? Does your friend? Your spouse?

-

Closing notes

This was a pretty quick rundown on designing and developing for the mobile web. I hope at least some of it made sense to you. For the next steps I would suggest you have a browse around for handheld style sheets and how to implement various style sheets depending on your audience (say a version for desktop computers – with IE style sheets – and mobile devices, you can even work on an iPhone version or versions for different sizes!) and see how you are getting on in regards to implementation, publishing and testing. If you have any comments or any experiences you would like to share then please do, I would really appreciate it