February 21, 2006
Improving Experiences: XD vs the CS2 Updater
Part of our role at Macromedia, and now at Adobe, is to improve and assure the quality of user experiences in our tools. Being a software company, we generally work with the teams at varying stages of product development and have the opportunity to give feedback, put across critical observations, make suggestions, etc. Sometimes things just piss us off and we go on a raging rant until someone listens to us. In keeping with the discussion of 'Experience Design', this is one of those occasions.
I've had to rebuild my work-station several times recently so I've had the opportunity to experience Adobe's CS2 updating process more than once. Words fail to capture the misery of the Adobe updater, so I present the pinnacle of tedium:
The idea is right; the CS2 apps all talk to a central application that manages their state and updates them as needed. But the implementation is pure misery. Not only do you have to babysit the updater itself, but have to be active every conceivable step along the way. EVERY update to be applied requires at least seven button presses and a system password, more button presses if the update happens to also require a user contract agreement. All this for each update of each product and sub-product in the suite. This is madness!
Seems the root of the problem stems potentially from the use of a 'front-door' type of application installation wizard (downloads, mounts and installs from multiple disc images) instead of something more integrated into the application. If you use small utilites like Adium or Quicksilver, their updates - whether extending their capabilites, or updating the core app - are perfected simplicity.
It's not just the small clever guys that have it right, either. Apple's OS updates are executed quite well. The updater remembers your system password once you've entered it the first time, and it assumes since you've selected the updates to be installed that you do in fact actually want to install the updates. The only tedium occurs for some of the big updates which require license agreements... but generally you can hit "update" and then walk away for a while.
There may well be good engineering reasons underlying the current CS2 Updater implementation, but speaking I'm sure on behalf of Adobe's entire customer base, I hope we get the opportunity to improve it.
Thanks for reading,
Ryan
Senior Experience Designer, XD
Posted by rhicks at 02:21 PM | Comments (2)
October 27, 2005
Design for Devices
Our lives are full of devices... we have Desktops, Laptops, PDAs, Mobile Phones, Televisions, Cameras and more. The user experience of these devices is going to start to converge. We need to look at how the experience translates to each device.
Andrew and I recently created a cross-device prototype for a media management tool. We designed the experience to connect media across a Desktop, Television and Mobile Phone, allowing users to organize, buy and most importantly, play their media. Much smarter people than I have known for a long time now... A successful design for one device might not work on another. So we set out to create a great experience across these devices, with specific designs for each. What follows are a few major areas to consider when designing across devices. They might seem obvious, but it can be hard to shake the tendency to design everything for the desktop.
Form Factor and Environment:
A small device will not hold the same content as a large one. A mobile phone is not a desktop monitor. Simple, right? Not really. A television is large... larger than most desktop monitors. Yet given the viewing distance and general atmosphere, this large screen will only allow slightly more content than the mobile phone. And speaking of the phone; it's small. But not only is it small, it is also in an atmosphere full of motion and distractions. So it can safely portray even less content.
Form factor and relative content load
Function:
People don't carry mobile phones to check the weather or buy movie tickets. Sure, they could do these things, but the primary task is to make calls. Also, as I mentioned before, the user is distracted when using handheld devices, so we need to consider muscle memory. A desktop monitor demands your attention, so interactions can be more focused... but a phone must compete for it. As a result, we must design for mobile with very simple, intuitive interaction patterns. Up should mean up, left should mean left. The screen can map physically to the directional pad, allowing the user to navigate much like they would a video game. This allows the user to interact without thinking too much about it. It also allows them to memorize key combinations. They might learn that weather is Right, Right, Right, Enter. They can do this without even looking. The television space has many similarities (we think.) For example, the user isn't directly interfacing with the controls, but doing so via a proxy (usually a focus rectangle of some sort). This means that Enter is used over and over, contextually. Buttons will do different things based on where you are on the screen. This is much different than the desktop experience where common wisdom tells us to make each button have a specific action tied to it. And remember, the user wants to watch television, not stare at our interface.
On non-cursor devices, map content to the function of the controller
Context:
Probably most important of all... Users might not want the exact same app on all their devices. We need to think like people, not like software. Yeah, it's cool that my Flash app can resize to a mobile phone and have logic in it to show content based on format. But this is the software talking, trying to lure us into its web. If we step back and think like people, we soon realize that we want specialized apps for each device, because I use each device for a certain purpose. The desktop is (generally), focused, at home or work, and mostly online. The mobile phone is only truly powerful when the user is out and about. I don't need a full-blown shopping tool on my phone, but perhaps a way to buy movie tickets or map theatres would be useful. Similarly, when they are at home watching television, they aren't in the mode of shopping or managing anything, so we should serve a very basic, yet rich, experience that complements their main task... watching television.
I know that this sounds really basic... and it is. But I find that it's good to step back sometimes and restate the obvious. I find myself constantly tending to do what I know. I know the desktop pretty well, and we have tried-and-true patterns for it. So when we do mobile or other device design, it's just instinct to apply those same patterns.
Ty Lettau
Senior Interactive Designer, XD
Posted by tlettau at 10:47 AM | Comments (3)
September 01, 2005
Dofus : Flash-based MMORPG Launches
About a month ago I heard about a game called Dofus. Despite the strange name, missing one 'o' from being something downright silly, I was instantly intrigued by the amazing art that filled the game's homepage.
I soon learned that the world of Dofus was a persistent online role playing game built in Flash! After spending some time with the game, I found that the French developer Ankama Studios had done something truly impressive.
When I think of "Flash games" I imagine Tetris-like knock offs or super simple scoring based games that involve doing the exact same action over and over. This is where Dofus is quite a departure from being just a "Flash game" and becoming something else entirely. With over 80,0000 people playing the game this summer, a society of players was formed. Each with multiple professions, abilities, and purposes that wove together the fabric of the game.
Yes the game is incredibly geeky; we are talking about a role playing game here. So the basics include choosing a class/race, customizing your character (tinting your clothing/skin since was nicely handled by Flash), and equipping with weapons/spells/etc. Apart from the turn based battle system, the rest of the game is spent in the community where you can chat with players, learn new strategies, form quest parties, barter for items/spells/currency, or just explore.
Again, most of this is somewhat standard fair for those who play multiplayer online role playing games. What I think truly sets this game apart though is its simplicity. The game is playable on Mac/PC/Linux either from in a web browser or as a stand alone Flash projector. This means the game can be played from anywhere and gives the developer complete control over distribution of the game. Not to mention essentially a free platform for them to publish the game. A MMORPG has rarely been so accessible; you can play at home, work (*ahem*), school, in a cybercafe�?....
So how much is it? At the price of about $7 USD per month, Dofus is a steal compared to other MMORPGs costing $30-50 to purchase and then the $10-15 subscription price. And it seems like there's a plan in place to keep the game interest intact; the Ankama staff says it will add something new every month. Considering the game is played in browsers and built on the Flash platform they should be able to do this seamlessly without complicated updates or downloads. I can't wait to see what else these French designers have planned.
It will be interesting to see how the numbers go now that the game is Pay to Play. Thoughout the month of August while playing, I talked with many players that said they'd continue to play only if new updates to the game were frequent. Others said it was only cool since it was free during the Open-Beta test this summer. Any current Dofus players out there with any thoughts?
I highly encourage you to at least take a look at the game, start a character and see the game engine in action. Consider the attention to detail with the beautifully created world and again that the entire experience is delivered in Flash; I think you'll appreciate and enjoy it.
Posted by rtandy at 03:11 PM | Comments (36)
July 26, 2005
Pages – Extension
Himgan started a good discussion about pages. XD creates a lot of RIA's (Rich Internet Applications)... in fact, I think we've about run the gamut of industry sectors to tackle. Thus far, we have yet to tackle a problem that really needs pages. So here's a quick list of reasons why the page metaphor can go back to the land of CMYK where it belongs.
10: It is redundant to time. In HTML, time wasn't really part of the equation - Flash and Flex and DHTML allow time to play its role. This is a kinetic environment after all.
9: Pages are crutches to bad content management. If you want to skip the step of figuring out content relationships, pages are a fast way to do it. But all content has relationships and can be shown contextually, and put away when not needed.
8. The 80%/20% rule applies here too. Just as we must consider what features the user actually uses, we must also consider the relevance of content. Put content that is relevant up front, not buried in pages.
7. Pages can cause development problems by requiring many different templates and layouts. RIAs deal with layout by simply reconfiguring the components on the page. And all the logic for this can be kept in one place.
6. It is impossible to fully trust "persistent" elements across pages. Users view page refresh as an entirely new page loading in. There is a moment of elevated stress when the user wonders if their information is still there. Forms are a great example of this.
5. Pages break continuity. They cause flicker and refresh that is disruptive and visually un-appealing. Here's a real-world activity to try: Walk down a busy street. Every 10 seconds, close your eyes for a few seconds, then open them again. It's only a matter of time before you run into something.
4. Pages make the user feel like they are moving around in the content. If the user is moving, the user can get lost. RIA patterns keep the user in one place, with content coming to them.
3. Transition, Transition, Transition. Using motion and transitions to move content around can show the user what is happening. It's a visual cue that they can track to see how the previous view and the new view of their application differ. As an example, think of a mapping site (Google, Yahoo, MapQuest, MSN... take your pick). When you click to pan or zoom, the page refreshes and the user needs to figure out where they are again. If the map panned or zoomed as a transition, without refresh, the user could follow it.
2. Pages make views, sorting and filtering very difficult. RIAs often function best when they can filter results or sort information. Sometimes the user wants to see thumbnails, other times they want lists. The one-page design allows for content to be shuffled around to fit the user's needs without feeling like a new result set. Oh, and speaking of results sets... ever want more than one search at the same time?
1. For the skeptics: Browser tie-ins. I wish I had a dime for every time someone asked "But it's Flash... what if the user clicks Back? We need to have pages... I know, split the Flash movie apart." "Umm, No." Well, using Flash or Flex, we can flag states of the RIA for the Back and Forward browser buttons to go to. We can send custom URLs to the Address Bar for emailing and bookmarking. Flash can dynamically assemble print layouts also.
Note: for more on custom URLS and browser tie-in, see: Kevin Lynch's blog
Ty Lettau
Senior Interactive Designer, XD
Posted by tlettau at 01:59 PM | Comments (5)
July 11, 2005
Thinking Outside the Windows and Pages
When we started creating a framework for Rich Internet Applications we soon became aware of the fact that there weren't a lot of good examples out there. In order to achieve the experience that we desire from an RIA, where simplicity and richness blend together, we needed to revisit a lot of the assumptions surrounding the design of both desktop and web applications. We have begun to establish a model for UE that we are pretty excited about.
Desktop applications have given us the “Windows� metaphor that we have become familiar with. These windows are the main organizational means for users to interact with multiple content elements and/or applications at a given time. This system allows users to multi-task, a capability that was seen as a revolutionary benefit by many savvy computer users.
Windows of various application on Mac OS
HTML brought us a non-linear “Page� metaphor that presents users with one focus of content at a time. This simple concept helped the fast adoption of this platform among novice users.
Typical sitemap for a website where each box represents a page
Unfortunately for RIA, these two existing metaphors do not fit well together. While Windows' multi-task capability is a great feature, its infinite flexibility could cause users to overwhelm themselves with a large number of overlapping contents. At the same time, HTML’s simple page structure, which provides users better focus, lacks the flexibility and dynamic organization that assists users in working on complex tasks.
You can think of the organizing principle for RIAs as Guided Multi-tasking. This model focuses the user on the task at hand by packaging contents and functions that are then organized and managed through panels (or pods). These panels are given weight of importance that is then expressed through visual treatments (e.g. size, brightness/fade, color schemes, etc.) in different task-based views. Between views, the changes that take place for these panels are enforced by use of animations (and sound in some cases). Through this method RIA strikes a balance between providing the multi-layered content/functions of the windows metaphor and the focus of the web page.
Breeze 5.0: displays panels in different configurations depending on the view (Slides & Discussion)
Flex Store: shows change in sizes (panels on the right) to bring different emphasis
Posted by hwibisono at 09:40 AM | Comments (7)
July 05, 2005
Shifting Perspective
Over time this blog will share many tenets of our design Principles in the interest of pushing application design along its evolutionary path. This entry will touch on a couple of our fundamental design basics. "Soul of the Application" focuses on a task from the perspective of the user (and their goals) and creates an application for them; "Simplicity", on the clarity of focus on that task.
Typical solutions follow a logical flow from an engineering and data perspective: a structure designed to facilitate every possible function while isolating individual steps branching out along the way. It's a matter of efficiency; build one app that can do it all and you're done. However, this architecture may do nothing to actually assist the end user in achieving their goal. Think about your experience moving through an average telephone menuing system. Too many layers of nested options create a maze in which it's nearly impossible to maintain a sense of context. In order to make decisions within this structure, the user must draw comparisons between their intent and the possibilities they can assess from what the structure reveals to them...
What are we really trying to achieve here? Do the options and architecture reflect this system's primary use-case? Is there a better way to help someone get to what they need, quickly, happily... More than likely there is, with clarity, focus, simplicity. Create a design that helps the user in their task.
Here are a couple of case-studies as examples of this thinking: our internal A/V system and people-finding map.
All features exposed at all times is contrary to actually assisting a user to achieve a specific task. The 'before' version the A/V platform installed at Macromedia required someone who simply wanted to host a conference call to think like an A/V engineer... one who knew the idosyncrasities of this particular tool. Many decisions had to be made simultaneously and out of any kind of cognitive order. Who is the application for? The application does nothing to help get a call through.
Figure 1.1 Existing workflow
The final version begins with three pre-configured paths and a free-form option. Of all possible uses of the A/V system, we assessed the few key uses and facilitated these with a single button press to set up the systems as needed.
Figure 1.2 Final implementation
Confounding content has the same effect as overwhelming interface. Our current method of finding the location of a colleague's desk requires drilling through myriad systems while filtering out intensive ancillary information, and finally arriving at a relatively cryptic visualization of their whereabouts.
Figure 2.1 Existing workflow
True, this process facilitates many other functions along the way – getting a phone number or supervisor information – and each step leverages a robust system, but is it the best way to simply find where someone sits? By focusing on the intended task (finding a location) and simplifying the presentation to only content related to the resolution of that task, a huge portion of the 'unneccessary' information is hidden... unless needed. (A rare look at a work in progress)
Figure 2.2 New map
Figure 2.3 Finding a conference room
by Ryan Hicks
Senior Visual Designer, XD team
Posted by rhicks at 06:34 AM | Comments (3)