The following is a wrapup report from Eli attending the Macromedia MAX 2004 conference. Since he was the only one this year from Web/Print to attend the conference, he went into many varying classes to get a broad range of information. Now, granted, he did not go into any purely design/graphics arts classes. However, he attended many production/workflow type classes, general Macromedia product information classes, usability classes, and some programming ones.
Below you will find all the information gathered, not by classes, but by category of information. Bringing the total 'picture' gained at this conference forward as a single cohesive set of thoughts. Some of the following may take the form of fully formed thought processes, some may just be small bullet points of information. Take it as you will.
There were a few classes that delved into this topic, and they all agreed on similar best practices for handling this. In the end, it boiled down to a few points. The biggest point was simply that you do need standards and procedures in place to have programmers, designers, and content creators have a smooth flow of information between them. Normally in most shops you cannot have those people all constantly working together, and therefore you need to have good procedures for how information should be created and passed off. In particular of importance to standardize on were the following: Information Architecture (how in general for a particular website/project how the data will be organized/presented), Runtime Architecture (Standardizing on PHP, backend systems, etc), use of Content Management Services (such as just using Dreamweaver, or using something more complex), Maintanence plans (knowing how you are going to take care of this product once it is done and having that worked into a bigger maintanence plan of your entire production), Quality Assurance Test Plans (How exactly are you going to test each product?), and finally Design/Code guidelines (Style guides, Information Design Guides, Programming standards, CSS creation standards, etc.)
An interesting point that was brought up a couple of times, was a designer giving a talk about how to work well in this 'new era' of dynamic content, with template based designs, etc. It was stated that "Layout and Design are two different things now. Content management requires doing Layout, and the Design is based on the Layout." It was stated that what worked very well was for a basic layout to be done, even in greyscale. No actual design work to be done to make the page look pretty, but simply a placing of 'what will go where'.
This basic layout to look at and work over, gains a number of things for you. First of all, the layout of course needs to be based on the content. The content being of course what is most important. So working on the layout, just where each block of 'stuff' will appear on the page, lets you make sure that your content and the layout fit. Secondly, it's actually the layout, for the most part, that can cause problems with the final coding of the webpage/application. The 'tricky bits' in creation of the page, all revolve around the layout of the content, not what a button looks like in the end. Therefore the layout can be used not only as a tool for ensuring it meets the content, but also as a tool for the designer and programmer to get agreement ahead of time of any potential problems. It ALSO ends up serving as a great tool for the programmer in the end to do the actual page construction based upon, since it is a nice clean look at the structure of the page to base the XHTML/CSS on.
It was also suggested then, to make the next step NOT be going straight to doing design. But to then work up a palette of colors, as well as a palette of fonts&sizes, etc that will be used throughout this project. The idea being that sitting down and coming up with this color palette and a font palette, forces you to think more in the 'CSS' model of standardization. It makes a document saying what titles, tag lines, etc should be yet still separate from the design. This keeps this thought process more organized, and keeps the end product from having 5000 different combinations of styles. This again serves as a great tool for the programmer afterwards, because they have a reference sheet that will almost directly translate into CSS styles that will need created.
Then, and only then, was it suggested to take the layout/blueprint, to take your palette's, and to sit down and crank out a final design, fleshing out specifically all the little graphical details of what appears where, at this point the blueprint can be fleshed out, and references can easily be made to the palette to ensure exactly what text/area gets what font/color.
The other thing that goes along with this, was a (almost mandate) to make sure that you don't even start the layout, let alone design, until you have the content! Not only does the content need to drive the layout which in turn drives the design, BUT, there is a bigger problem that often happens. If an artist is assigned to a project before the content is ready, then it is in the artist's nature to start working on buttons, page decoration, etc (the chrome). Lots of time will end up getting spent on this chrome, which quite often in the end, will overpower the content. The web is an information medium, it's the content that is most important. Therefore the easiest way to ensure that the content gets the highest placement, is to always start with it, and work downward.
There was more discussion also on the integration of CSS into the workflow, and some changes that it means for production. One interesting point of data is that in the room, when a call of hands was made, 30% of the room was using full CSS for their websites, and 70% were using a CSS/Table Hybrid. Noone was using older technologies at this point. That is a huge change from last year's conference. Another note, was similar to our situation at STScI, that there is a trend throughout the industry to be reducing their web staff, while at the same time requiring more out of them, putting everyone in a time crunch, and needing to take every step possible to save time. It was also recognized, that simply because of the decoupling of content and design with CSS, that while DW is still a great tool to use, that using it in design view is becoming less useful, and more handcoding is being needed. There isn't much Macromedia can do about that (but they are trying); however, they are doing what they can to make the handcoding parts easier as well.
There was a list of some major 'cleaning up the workflow' points when using CSS that were brought up, they were :
Alot of the information in this section comes from the fact that Macromedia has created a group it calls 'XD' within itself which standards for eXperience Design. This is a group it has created of graphics artists and programmers working together to 'figure out' for the rest of the industry what works, and what doesn't in a User Interface/Page Design. They are doing lots of this work, and sharing their knowledge. Not only via giving classes like the ones I attended, but also via building their tools to help create things the 'right way'. Hence, for example, the 'Halo' look/feel that they have developed and that many of the new products help you use easily.
One interesting topic of discussion is how there is no common language of 'design' for the digital world. Conversely, for example, in the architect world, if one architect turns to another and says 'plinth', they know what they meant, and so does the contractor looking at the blueprint. However, the digital world doesn't have that, as terms are created/dropped as needed and almost on a whim. They are trying to look into helping to create some standard terms for the industry.
The head of the XD division, a self proclaimed 'designer guy', talked about things that we USED to always think were true, they were known facts, and in fact are now false. These are:
There were also, a number of new design guidelines that are surfacing in this new era, that all are needed in mind to create the best User Experience:
A quick topic, but it seems that Flash Video (.flv) files are potentially something for us to look into. Since 96% (according to Macromedia) of browsers have the Flash player installed, 96% of our audience can immediately see a Flash Video without worrying about getting a specific player/plugin. They seem quite easy to make with a simple 'convert' feature built into Flash. Also, while you CAN program your own flash player to look/feel just like you want while playing the .flv, they have a development kit for Dreamweaver (free extension), that gives you a few built-in basic flash players that do just that, plays an embedded video with different interfaces.
Also, if you buy/install the Flash Communications Server, it doubles as a streaming server and can stream these videos as well. At that point you can also do some very neat tricks, such as having the server automatically generate thumbnails, create chapters, do clipping, manage playlists, etc.
There was alot of good information given about best practices for making and coding in Flash, much of it disscussions of how best to use Flash NOW, versus years ago, given many changes to the product over time. The first main thing revolved around ActionScript. The first big part being where your code should be. General best practice at this point, is that all actionscript should really be in .as files, using code editors to edit, and being included with the classpath directive. It should not be on movieclips, it should not be on the stage, and it should only be on frames where it needs to be to attach a component. Keeping all of the code in .as libraries ensures that you never 'lose' any code. You never end up trying to track down what is going on and not finding the part you are looking for, it's all in one place. Also, that way, it can all be under code versioning controls if you wish.
As a side note, it was mentioned that nowadays it is getting to where you end up using design mode less frequently. As you wish to do more complicated projects, things beyond a simple little banner add, or flashing box, that it ends up being easier in the long run to do as little as possible in the design view screens, and as much as possible via actionscript, in the manner referred to above.
There was a very good discussion about understanding 'frames'. As it was said: "Frames Own You!". Everything in Flash is based upon the frame tick, and everything happens during/around a frame tick. understanding that ends up helping you code better. Drawing to the screen can only happen on a frame tick, so your code needs to allow the ticks to happen. Also, at the same time, Flash does NOT want to let a single frame take more than 15 seconds. If it does, you get the 'warning' that many of us have seen when you compile about 'This program may degrade performance of your computer'. If you truly have more than 15 seconds of code work to do, you need to break it into multiple frames and schedule it to happen over time.
In general, scheduling things to happen over time is a good thing because it keeps the frames ticking, which makes flash happy. So using onEnterFrame to activate your code, and using setInterval and similar scheduling based functions (Tween, etc) to do the work is much better.
A brief discussion of performance brought out a few tips that should be remembered. One was the rule of three. In Flash every 'object' lookup (ie: this.myvar) ends up being a string lookup in memory, and is very performance intensive. Therefore, if you are going to use the same lookup 3 times, it's best instead to save that value to a local variable, and use the local variable instead. Another performance tip is that text fields, labels, etc are the HEAVIEST perfomance eater because of necissary calls back to the system. Therefore, you should never have more than 200 instantiations of text at one time. Bring things up and down as needed if you really need more, instead of loading them all at once. Also, the final tip was again back to the frames, that doing your Instantiation in passes is better than doing it all at once. It gives the appearance of better performance, and helps the player run better, instead of it trying, for example, to load 12 images at once on the screen in one frame, have them pop in one per frame over 12 frames. The player runs a bit better, and it's actually a better looking product to the end user who sees them 'load in', instead of waiting for them all to suddenly show up.
This information is a bunch of tips for doing usability testing well, and was mostly given by a PhD in Human Interactions, who runs one of the most respected Usability Testing firms around. One of the main things to first note about usability testing, is that it is only good to discover how well users are performing a specific task on your website. It is not a tool to determine what you might want to build next, and it is not a tool to discover if people want or need your information/product.
The biggest problem, it was stated, about doing usability testing is coming up with the right goals. Most usability testing fails to varying degrees because the wrong goals were chosen, so you should take the time to ensure that your goal is the right one. For example, focusing on the terminology used on the website and how it affects the user's experience, when in fact the main problem is that you have a lousy search function. Or focusing on the color of your visited links and if people understand the concept, when in fact they are having problems deleting things from their shopping cart, etc.
Now, on running the usability test, there were a number of steps to follow, and a list of pitfalls to avoid along the way. First of all is to define your user. Pick one (or more) roles of typical users of your website, so for example, Astronomer, Amateur Astronomer, Scientifically Interested Public, etc. This may or may not go more specific into demographics, but only if you have a reason to. The main idea, is the basic roles of people you have visiting your website.
After you have those roles, you need to pick the people to test. You need approximately 6-8 people to take the test, PER ROLE that you want to see the results for. Then you need to write a quick screener, a few questions to ensure that you are getting the proper people to match your roles. You are going to probably need to pay people to get them to come in and do the testing, suggested $50 for the first hour and $10 per hour afterwards. Alternatively you can give away free stuff (Hubble Posters/etc) which can often work.
One big note, that was brought up multiple times was this: Do NOT use friends, family, or co-workers to do this testing. Repeat, do NOT. The data you receive will be inherantly flawed, because they will have built in biases towards the site, for or against, and/or will have already solidly built usage patterns which will not directly translate to an 'average user'. You NEED to get external people to come in and do the testing.
You also need to write the tasks you will ask the users to do. The hardest part is to ensure that the tasks are written without any bias in them , and in a way that will give you the information that you want in the end. For one thing, don't use words that are used on your website directly. IE, don't say: "Ship some wine to your friend.", when your homepage has a huge button with the word 'SHIP' on it. It biases the user because they are already thinking 'ship', when in reality noone goes to a website to 'ship something' to someone else. They are going to buy some wine for their friend for their birthday, and have it sent to them. Similarly, you need to make sure there is no biasing just in the wording, saying "Try to send some wine" implies that it is going to be difficult, they are only to 'try to', they may not accomplish it, versus "Send some wine". At the same time, make sure to give them full scenarios, not specific tasks. People when coming to a website do not typically have just a specific task in mind, they are working out a scenario. Therefore, instead of "Buy two cases of wine and have them sent to address X" ... Tell them that their friend Bob's birthday is coming up and that you are thinking of buying him some wine for his birthday, and that you are coming to this website to see what wines they offer, and in the end picking one and buying it for him. Doing this helps give them the context, and puts them more into a frame of mind of being a normal user of the website, as opposed to someone with a very specific task in mind, which would never normally happen.
Next is actually running and moderating the sessions. First of all, you need to make sure that you are recording the session, both what they are doing visually, and their voice talking about what they are doing. As they go along, regularly prompt them with 'bland/dry' questions to make sure that they are talking and saying what they are doing. Statements like: "What are you working on now?" or "Please remember to keep talking outloud." are excellent. Make sure that you stay away from any biasing questions, such as: "Are you trying to do X right now?". Similarly don't ask them if anything is easy or hard, people are much more likely in those situations to always answer yes, no matter what the question. While this is happening, you need to take good notes, writing down everything that was said/done/etc. Don't bias the data by leaving something out because it doesn't support your goal, or because you know about that problem but it would be too hard to fix, etc. The final thing that you should do while conducting the test, is to have more than just the test conductor in the room at the same time. You should have some of the developers and designers in there, not too many, just a couple, and sitting back and not saying anything. But having them specifically see what is being done will GREATLY help them fix the problem in the future. An alternative to this can be if you do full video recording of screen & person, that those can be shown to the developers later. The product team should see at least 3 of the users, if you don't want them to sit through all of the sessions.
Finally, in the end make sure that you do something with the data. Pull the low hanging fruit off first and hit those. Take the rest of the data, and divide it into high, medium, and low issues, based upon how serious the problem was to the user, NOT how hard it will be to fix.
Contribute 3 has some neat new features, but most importantly, should we choose to pay some more money for it, Macromedia is now making a 'Web Publishing System' that integrates with Contribute fully. This is a CMS (Content Management System), but under the standard Macromedia philosophy, is keeping it simple and making sure it doesn't get in your way, just helps you out, unlike other, million dollar systems, that end up making everything very complicated in the end.
Essentially this server runs on a separate machine (it can be the same, but doesn't need to be) than your webserver. It provides a couple of nice features over using Contribute without it. First of all, instead of passing around keys to the users to configure their contribute, they log on to the server through contribute and it downloads their settings/permissions/etc. The admin can log on and change those whenever they want, and the changes will happen when the person next logs in.
When using the WPS, Contribute still does it's normal checkin/checkout functions from the webserver; however, as it does those, it is also connecting to the WPS and sending events. This ends up doing a couple of things, first of all it logs all activity that happens and you can view that. It also will handle sending out email alerts about data that has changed in whatever manner configured. The really nifty feature, is that the WPS is extensible, just like all of Macromedia's products, and you can build your own hooks into it to do what you wish. So, for example you could have a sitemap that is being automatically built as people are checking files in. You could also handle the automatic moving of files from dev to live when a file is published (as opposed to being sent for review), and so on.
There are a few things about Contribute 3 that they have added that are nice. Shared Code snippets/Assets are nice, giving complex blocks of HTML that are regularly used an easy way to be added, which could even be PHP code. On that note, you can change the default extension of all files, to, for example, .php so that all files will be php parsed, and snippets can be PHP based. You can also, via MSIinstaller, configure a custom install of Contribute, with your own Configuration directory, to end up placing your own extensions/etc into Contribute to all your users easily. Finally, there is now the feature in Contribute to only show the user SOME of your CSS styles. Thereby letting you hide all the ones that you don't want the user to potentially use, and just giving them the safe formatting ones.
Just a quick note that there was alot of discussion at this conference about the future of the web, and in many senses, the lack of it. Not the Internet mind you, but the web. The fact that many other uses of the internet are actually seeing astronomical rises in use, such as AIM, services like iTunes, news aggregators, etc. This is also coupled with the fact that more and more internet use is switching away from the desktop. Much more cell phone use, PDAs, etc. While noone expects the web to disappear anytime soon, Macromedia is really looking towards this, and is doing everything they can now to help us flow with the tide (such as their Creation of Flash Lite, for mobile phones, and working on FlashCast, the mobile phone flash network), etc.
Just a small section here to bring up some topics that were discussed about designing for cross browser compatibility. First of course that while it has it's problems at times, CSS greatly helps supporting different browsers with less effort. Of course, with the caveats that you need to be designing the page to work well with CSS. Every little 'trick' you use, is going to require extra work to make that trick work in all browsers. You have to think, does the page need to look identical in every browser? No, probably not. How negative is the affect in another browser ... Is it just 'a little different?', unpleasant but usable? functioning but usable? nonfunctional?
There are some problem areas with usability right now. For one thing, the rate of different devices being used to access the web (mobile phones, PDAs, etc) is growing. Another thing to worry about, no matter what your statistics say about who's using your website, is some specific users. Many schools are Mac-centric, even if the overall usage of Mac's is down - Do you want to alienate schools? Many government agencies have standardized on Netscape 4 as their browser, what about them?
Ok, time for the big sneak peak session here. For those that don't know, this is where they show off potential future technologies they will be adding to their products, some of this stuff might make it to the next version, some of it might not. But it's stuff they are looking into. I'm just going to give a laundry list of these items here that were shown:
Ok, following are just a bunch of little things from my notes that didn't warrant an entire section, some of these I may have more notes on in detail, but just didn't feel the need to do a writeup on them, if you are interested in any of these topics, just talk to me.