I am still working on getting my Yahoo-map-based travelblog prototype online, the Flash image-uploader is working fine, but there is an error once you have a number of users trying to connect / upload at the same time. Stay tuned for updates!

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

But what gets me going of late is the inability of some websites to display their PDFs properly…

.

The problem with PDF links

I was reviewing a website a few days ago using my usual set of browsers (IE 5.5 - IE7, FF2 FF3, Opera 8 - 9.5, Safari) then I was going through a product page and clicked on a link to read more about a link called “Course documents”. This was when my old test machine’s fans started spinning up and the task manager showed a significant increase of Memory and CPU usage. Acrobat was loading up while IE6 and IE5.5 came to a grinding halt. After about a minute of nothingness the browsers displayed a 3 page PDF with a 1 page full-size image and 2 pages of information about the course.

Now in that time I, the average user, could have been under the impression that the site is crashing my browser, so I would have tried to close the browser forcefully. Or I could have been saying “F*** this, I’ll go elsewhere”.

Not showing your users what link opens a PDF is one of the most annoying things you can do to your users! Not only that, it is a usability and accessibility issue!!!

So I wrote my report to the client, asking them to indicate their PDFs properly. This is what they came back with:

Well done, at least you have the word “Download” appearing within the link. Still not best practice, but at least something - if you are f***ing lazy. So I sat down with the client again and suggested a couple of ideas to his development team:

.

Best practice for PDF links

1. Link location: think about moving PDF downloads either into another location entirely, or - if that is not possible or not wanted due to the design and layout - distance the PDF link from other links.
2. Show a file size: here in the EU we still have quite a number of users with dial-up or very slow connections, so it is best practice to show your users what they can expect and how long it may take them.
3. Display a PDF icon: the best visual reference that the link you will be clicking on will be a PDF

In the end the problem was finally solved:

.

Conclusion

This was an interesting exercise with that client. And I really wished everyone would do this. Displaying PDF links properly isn’t difficult, it makes you look a lot more professional and you make your site a hell of a lot more usable and accessible. Come on, do your part!

Yesterday Google announced an update to their search engines with the help of Adobe Labs. Read more about this new development after the break.

.

So how does it work?

As part of their Open Screen Project Adobe has released a technology to both Google and Yahoo that enables the engines to crawl and index swf files.

Adobe Labs developed a Searchable SWF library for Google to develop an algorithm for search engines that explores swf files in the same way that a person would, by clicking buttons and entering input strings. The algorithm then remembers all of the text that it encounters while going through the file, and that text content is then listed and ready to be indexed.

In addition to that, any URL linked from the flash file will also be indexed in the same way as normal text-links would. Please note however that this only applies to static and dynamic text, text that was “broken down” in Flash to an outline will not be found and indexed.

.

Limitations

A few limitations remain in Google’s ability to index SWF files:

1. Google’s crawlers do not execute some types of JavaScript. So if a web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed.
2. Currently Google does not attach content from external resources that are loaded by your Flash files, meaning if a Flash file loads content via XML, HTML or another flash file then Google will separately index these resources, but it will not (yet) be considered part of the content of the Flash file.
3. Flash files using bidirectional languages (such as Hebrew or Arabic language) are currently not indexed as it provides a difficulty for the algorithm at this point in time.

Having said that, Ron Adler and Janis Stipins (Google) already commented:

We’re already making progress on these issues, so stay tuned!

.

Good times for the flash designers and developers, however, making your Flash files visible is one thing, actually making a ranking difference is another. I would think we would have to wait a couple more months until Adobe’s library and Google’s algorithm improve indexability and deep-links, and then we’ll see how we go from here.

.

Additional reading:

• Adobe’s Open Screen Project
• Google’s Weblog
• Adobe’s SWF searchability FAQ

I came across a couple of odd bits when developing a website - it seems like Firefox 3 is displaying a floated element’s width of 100% correctly, whereas FF2 would not fully acknoledge the width unless the element was previously set to “clear: both;” (or something along those lines, unfortunately I am still relatively new to the CSS cut-up world.

So we decided to install FireFox 2 again on the design-machines next to an existing FireFox 3 installation without causing any issues with the extensions or other settings between the browsers. I got it to work pretty much instantly on the first go, but since colleagues and friends were asking about how to get FireFox 2 to work with FireFox 3, here is a quick step-by-step guide after the break.

.

Step 1) Install FireFox 2 Portable

Quickest way to get FireFox 2 to work without any problems is if you grab hold of FireFox 2 portable. Get it from PortableApps.com (direct link to FF2Portable) and install the application, ideally into a separate folder (such as ‘C:\Program Files\FireFoxPortable’)

.

Step 2) Enable FireFox 2 to run next to FireFox 3

Firefox 2 Portable will not allow you to open another instance of the browser by default. What we need to do now is to make sure FireFox 2 Portable allows us to still use FireFox 3. Download the file ‘FirefoxPortable.ini’ below and put it into your install directory:

Please download the file here: Firefoxportable.ini (644 bytes)

.

Step 3) Install all your extensions for FireFox 2 Portable

Lastly, all you need to do is to get your favourite development addons onto FireFox 2 Portable. This works in the same way as you would install any addon for FireFox (1, 2 or 3), and to ease your search, here is my recommended list:

• FireBug - Probably THE most useful addon of the lot. You will need to install a previous version, which you can find here
• FireFox Accessibility Extension - this tool aids developers in testing websites to accessibility standards and under conditions such as not having CSS or scripts enabled. Furthermore, it allows users to test their website according to standards such as Section 508 or WAI. Download the addon from here
• Fangs - A very very useful and powerful screen reader emulator. You can get the addon from here
• Web Developer - another nice toolbox for testing your website with a number of tools, cookies, image and source options. Download the addon from here

.

Well, there you have it, FireFox 2 running alongside FireFox 3 as a standalone without any problems.

Usability testing will reveal if the flow of the site works, and accessibility testing will ensure that our site complies to any relevant accessibility guidelines.

-

User testing - preparation

Before you begin testing your prototype or pre-live-website with other users you need to make sure
that you:

• Have finished all relevant pages according to the brief / scope discussed. Make sure nothing is missing still
• Have annotated relevant sections, panels or functions: “If you are coming from page X this drop-down will be pre-populated with Y”
• Have gone through the prototype on your own and have made notes and / or necessary amendments where you struggled or had omitted functionality

Once you have reached the point of a project where you would like to invite users for testing, it is time to look for a certain kind of users - the users you successfully identified as the target audience, but also a number of “general public” users who may or may not be part of your target audience. After all, a website can be viewed by anyone. A typical group of users consists of at least 5, preferably 10 users, and should take no more than an hour per user. I hope your / the client’s budget caters for that, as well as possible payment for the users and or refreshments / lunch during the test as well as equipment (such as PCs, desks or cameras).
User testing - preparing your users

Before you being testing your prototype, please make sure that you have given your users (friends, colleagues, students, spouse…) a brief overview of the client and what the client is going to do with the website (such as “The client you are testing the site for is a new company within the perfume industry. The main focus for this website is about informing potential customers about the range and the brand, as well as giving additional information and an order facility”).

What the users need to be aware of:

• The users need to be honest in their responses. If they cannot find a bit of information they are after then it may not be because they are not web-savvy enough, it could just be that you did not link it properly!
• The users will be asked to complete a small number of tasks (”Find a product”, “make an enquiry”, “make a booking”, “find section XYZ”)
• The users need to verbalise what they are doing and why they are doing it. This will help you later on to amend or improve the prototype
• Just like when browsing a website at home, users should take their time researching into the prototype’s offering. If they spend a lot of time reading text and looking at pictures, then let them, after all, this is what the users will do once the site is live
• Inform the users that you will be making notes and that you will answer any questions they may have during testing and that you will explain functionality.

It is important that you yourself take over the role of an observer, and that you let the user do the tasks you asked for without any hinderance / distraction from yourself.

Once your prototype is ready for user testing you can go through any or all of the following options:

-

1) 1-on-1 user testing

This is one of the quickest, easiest and cheapest options: you sit down with a user and let him use the website without any additional equipment other than a notepad and a PC.

After sitting down with the user you explain that you are going to show a prototype for a new client’s website and explain briefly what the company is about, what they intend to sell and what you hope to get out of this session: you want to see if the user understands the flow and navigation of the prototype and if the user finds it easy (or has problems with) finding a product or making a purchase / booking.

To start off with, let the user get a feel for the prototype and how it interacts, with a few explanatory notes (certain prototype creating applications create very rudimentary HTML and may require quick explanation of drop-downs or what items will be dynamic). Then let the user complete the tasks you set out. Stay quiet, answer questions, but do not interfere if a user does not take the route you would have taken.

-

2) Unmonitored user-testing

This type of testing requires you to put the prototype online somewhere (ideally in a private or password-protected network) and send out a questionnaire to your test audience.

What you need to make sure of is that your prototype is very self-explanatory, and that you have added notes on all pages with important functionality (such as changing menus depending on where on the site you came from).

The questionnaire should have a same introduction as you would give at the 1-on-1 testing, followed by listing the objectives of this test and the tasks you are asking the user to do. Each of the tasks should have a couple of questions associated with it, ideally each of them with a rating and an optional comment field. Here is a sample questionnaire, feel free to use and edit as appropriate:

Please download the file here: Whatwasithinking - usability-questionnaire.pdf

-

3) Monitored user-testing

Probably the most expensive test of the user-testing cycle: monitored user testing. In essence, it is the same test as the 1-on-1 test, but this time the user is being video-recorded. Video recording can be a bit unnerving to a user, as such it is very good practise of sitting down with the user and having a very informal chat about what is going to happen and what is expected. Have a chat with the user about anything, it doesn’t matter what, as long as you can get the user more comfortable in participating in the test.
Another way of testing is using two cameras, one for filming the user using the computer, and one for the eye-movement. This is a very expensive way, as it involves a special kind of camera (a normal web-cam would not suffice) and monitoring software, which will overlay the user’s eye movements to another monitor, showing what the user looked at when he clicked his way through the pages. This type of testing is usually undertaken for projects of big (and I mean BIG) clients or public sector / state-run websites.

-

User testing - analysis

After conducting your user testing you will probably have written down a couple of pages of notes. It is now time to prioritise these notes accordingly:

• Critical - usability issues preventing the user from completing a task
• High - usability problems causing frustration, misinterpreting information given or frequent
  attempts to get to a result
• Medium - usability problems causing minor delays or problems which are overcome once the user understands or is made aware of errors
• Low - cosmetic problems, wording problems

Once you have your findings and analysis completed you will want to write a report to the client as well as an action plan on the next steps of the prototype and consequently development.

-

Accessibility testing

These days it is becoming more and more important that websites (especially websites of bigger companies, public sectors and government-run) comply to certain accessibility rules.

Accessibility testing means to combine software tools with human use and judgment. Sadly, there is no
automated way to check if your website complies with the Section 508 provisions or the Web
Content Accessibility Guidelines.

-

Accessibility testing - the automatic / software tests

Automatic tests are fairly straightforward: does your website comply to certain standards? Does it validate successfully?
Tools to test are plenty, here is my suggested list:

• FireFox extensions: FireBug, Accessibility Extension, and the JAWS-emulation FANGs are vital!
• W3C validator
• W3C CSS validator
• A-Prompt’s Web Accessibility verifier

It is worth trying all of them, as errors can easily be checked and consequently amended in the development phase.

-

The manual tests

When doing manual accessibility testing (human accessibility testing) you need to assess:

• Whether the website complies with any government set guidelines
• How language and visual cues, tags and labels are used
• If the website is compatible with as many current browsers as possible (at the moment we usually test for IE6, IE7, latest version of Opera, Safari for PC and Mac, Firefox 1.5, Firefox 2 and Firefox 3)
• How easy the website is to read and scan over
• If common fonts are used or (if uncommon fonts are used) replaced
• Whether a style sheet has been used to control the site and whether the site is usable and accessible without stylesheets
• If the website uses any kind of scripts or Flash, and if it is still accessible without
• Whether the website sports efficient navigation

Once you went through the tests above, it is worth writing up another report to the client, again with an action plan on where to go from here.

-

Closing comments

User and accessibility testing comes in all kinds of forms and flavours, some cost money, others just time. My suggestions above are a small part of a best-practice approach that I have been using over the last couple of years, and so far it has been serving me well, with about all of our sites being fully accessible and adhering to all current web standards.

Disclaimer
Again, this was just a short run-down of this vast and complex subject. Some of the above may most likely be different from how you have learnt (or read up on) information architecture and accessibility and usability testing. To be honest with you, so have I when I first came into contact with the industry I am working for. You are working in an industry that is most likely not considered the “average website”, be it websites for the music industry or landing pages, B2B sites or what have you. The user base is sometimes entirely different, you can expect your users to be a lot more experiences in some industries, and maybe less savvy in others. Certain heuristics or standards may not necessarily apply. I am not telling you to go and use ‘my’ methods described above, this is just how I work, and it some of it may just not apply to you. At the end of the day, looking at your industry, your client’s requirements, the client’s competitors and its target market are what will give you the best ideas for approaching your project.

I hope you enjoyed reading the article and if you have any questions or suggestions, feel free to comment