Article: Design For Action

Below is an article published in 2009 while I was working at Microsoft as a Technical/UX Evangelist on the MIX Online team. The site has since been retired and the team re-orged, but the sentiment of the article remains relevant, IMO.


Design For Action

As UX Professionals we have to think about moving away from traditional mouse-based interactions and consdider a new way.

I still use, flyout panels, rollovers and mouse overs when designing user-interfaces, but [in 2009] I’m [rethinking] these methods, especially when designing for [mobile].

Relying on a hover-state/mouse-cursor model hinders interactions and obfuscates the real intent of the design. Although these conventions may work for the desktop or laptop scenario, they impede interactivity and frustrate users in other contexts. [Now in 2016, we know this all too well, huh?]

In doing research for this article, I found a great article by Bill Scott, “Musings on Mouse Hover” about the benefits of rollover/hover-states. For interfaces that require a mouse, I generally agree with Scott. He writes:

Use hover to create a more lightweight but engaging way to cue the user to hidden functionality. Use it as a way to provide just-in-time details. Use it to keep your page visually simpler providing what is needed when they are most curious.

But what happens when there’s no cursor wandering around the user-interface? What happens when buttons are activated on-click, gesture, or similar interaction? Answer: nothing is lost if the hover-states are *enhancements,* but if they’re an integral part of your UI, users will get lost and frustrated.

Context & Clarity

We have to make user-interfaces clear. Functionality needs to be visually apparent and indicative of what the user should expect. We can no longer rely on images lighting up, buttons or sections gaining focus, alt-text giving instruction or dropdown menus appearing when a cursor triggers them.

Again, in the touch-scenario, the developer/designer cannot rely on an omnipresent cursor.

However, “The Great Roadrunner Race” (another Go, Diego, Go! game), which uses mouse-position to dictate the movement of the characters and keyboard interactions for things like jumping, leads to frustration … why?

Stepping Outside the Laptop/Desktop Dichotomy

As user experience professionals, it’s our job to step outside the laptop/desktop dichotomy and consider the myriad devices on which our interfaces might now be available. I’m picking on hover-states here, but the problems include screen-sizes, required plugins, and download times, too.

How do you accommodate for not only screen resolution and different browsers, but also different form factors, input mechanisms, and platforms such as mobile and various providers?

Drop us a line below, and be sure to follow us on Twitter @mixonline.

Article: How We Work (And Sometime Skip Some Steps)

Below is an article published in 2009 while I was working at Microsoft as a Technical/UX Evangelist on the MIX Online team. The site has since been retired and the team re-orged, but the sentiment of the article remains relevant, IMO.


How We Work (And Sometimes Skip Some Steps)

Many, if not most, of us work on small teams with short deadlines, and can’t afford new headcount or the hours to have multiple rounds of internal and external back and forth approving wireframes, comps, developing, publishing, and maintaining the sites and applications.

Is there a way to manage the current standards of meetings and workflow?

Battling with the developer/designer workflow is one challenge I experience consistently and hear about from fellow designers and developers on a regular basis. For years I’ve worked with different systems, whether simple organic naming conventions and shared folders, or mega-custom CMS systems that managed a nationwide network of offices. Depending on your situation, you may be at either end of the spectrum. Most of the time, however, I find many small agencies and freelancers could benefit from some simple source-control and some workflow tricks that can make the relationship between developers and designers and clients a bit more effective.

Oftentimes creative assets, whether they be visual comps or individual assets, are “handed over the fence” to the development team who then is responsible for building the site or application and incorporating the stylesheet and visual aesthetic (not to mention the possible interactive aspects or animations). There are many great developers out there, and they can take visual comps and assets and build out a solid, valid, functional site or app. We all know, however, that no site or app is built and immediately published. The designer — not to mention the client — always requires changes, but changes to design after development is time-consuming, costly, and often-times breaks what’s already been built.

The information below is strongly influenced by the folks over at 37Signals. I was able to take a workshop and see their session at The Future of Web Design Conference in New York last year. I totally “drank the Kool Aid,” and found that the methodology — if used correctly — can save time and effort for websites or applications that are small to medium in complexity. Now, I’m not going to go into the “discovery” phase of the project; that is to say, I will not address what you do before you have collected all your research, met with the client, defined the scope of the project, etc. Rather, let’s start when you’ve rolled up your sleeves and are staring at a blank sheet of paper.

Or, perhaps, whiteboard.

Whiteboarding and Sketching

We generally start out in a conference room in front of a wall of whiteboards, markers in hands, laptops fired up, and ready to roll. At this point we’ll generally use one whiteboard to write down and brainstorm features, then translate that featureset into a set of *crude* wireframes, thrown up in blue, red, green, and black. Of course, the complexity of the problem we’re trying to solve may require a few rounds of this, but at that point, we simply pull out a digital camera and take a photograph of what we’ve worked out. Then we start again with the next problem we have to solve, continuing to do this until we have enough to at least start trying to build out the framework of the site or application we’re working on.

Source Control and Project Management

Next, we’ll generally set up a project in Team Foundation Server (TFS). For those unfamiliar with TFS: Microsoft Visual Studio Team System 2008 Team Foundation Server is a team collaboration platform that combines team portal, version control, work-item tracking, build management, process guidance, and business intelligence into a unified server.

For most of the projects I work on, the developer is working in Visual Studio. For me, now that Expression Web 3 and Microsoft Expression Blend 3 include the ability to access source-control (at least using TFS, if not others) there’s rarely a case where I have to operate in Visual Studio, which runs TFS. There are many different software available used for source-control, all easily found on the web. For those who are used to checking files in and out, I’m sure you can sympathize with those who don’t. Being able to work simultaneously with others on the same project and maintain locks on files, a history of changes and versions of documents is invaluable.

Project Management: SCRUM

When we first decide on a project, we set up a standing weekly meeting, lasting one hour, with the whole team. During this meeting we go through a short demo of where we are with the project, address open issues from the previous week, and open new issues and suggestions. Additionally, we’ve found it very useful to also schedule a *daily* SCRUM meeting lasting only 15 minutes or so with just the key players (in our case, usually the one designer and one developer working on the project) to show what they’ve done in the last twenty-four hours, and raise any blocking issues. As you can imagine, the combination of competition to see who can get the most done, coupled with the daily meeting to get problems out of the way, is very conducive to quick results.

Functional Wireframes — skip some steps

When I worked at agencies, and often with those I engage now, the next step usually leads to Adobe Illustrator or Photoshop and wireframes. From these static wireframes, the resulting images are rolled up into an Adobe Acrobat .pdf; and they’re sometimes terribly artifacted during the compression process. In the past, the progression usually went: Static composites (comps) created in Adobe Photoshop or Illustrator, those comps turned into discreet assets and redlines created to callout margins, padding, font-sizes, etc … From there, we as designers / Creative Directors would throw it over to dev and trust that their team could get it done, of which, of course, they generally did a decent job. Yay for talented web developers.

What I’ve been doing lately, though, when designing websites is moving directly from the whiteboard into wireframing up the site directly in HTML and CSS. For this, I find the 1kb CSS Grid very useful. Using this set of CSS styles, it’s very easy to lay out a useable, skinable, HTML + CSS site, that not only conveys the structure and flow of the site to your client, but provides actual usable code to the development team that’s waiting to begin building the site.

The result is that not only do the wireframes generally look like the usual structural wireframes we present to clients at the initial stages, but they can be semi-interactive, which helps clients understand the flow of the site. I often find that this is where clients provide the most revisions, and by making important links working links, by making navigation working navigation, the client and developers are able to understand the user-experience better, and either (hopefully) buy off on the functional-wireframes, or see problems at this stage, which can be addressed before major development or creative assets need to be changed. Additionally, a benefit of this methodology is that, so far, nothing is thrown away – there are no Illustrator files that are simply archived and never touched. No Photoshop comps presented that need to be revised again and again, only discreet pieces or content. When text is laid into the content structure, it looks *exactly* as it will when it’s converted from image to HTML, because it never was an image to begin with. If you’re going to lay in Lorem Ipsum, might as well make it optimally editable, right?

I also find this methodology works well when creating applications using Silverlight or WPF using Blend 3. Why go through the hassle of creating wireframes in Illustrator and Photoshop, only to export those into another application, which requires an export of your work to a new file-type in the best of situations, or a redo of your work most of the time? Why not simply start out working in Blend and create your wireframes there? Take a screenshot of the XAML wireframes and create your visual assets in Expression Design or Photoshop, then return to Blend to build your application.

Once the wireframes are approved, the application can then – generally – move into two different, parallel tracks in development of the site: aesthetics and functionality. We’ve been using TFS or some other source-control up until this point, so all we have to do now is give our developer access to the html and CSS we’ve been working with, and from there they can do the build of the site using whatever technology has been agreed upon. This helps significantly, too, with the normal “translation” from a visual comp to a working framework. No longer does the visual designer have to provide redlines showing the margins between columns and layout — that information has already been delivered by virtue of the stylesheet.

While the visual design is being adapted, refined, and approved by the client, the development team can be working in parallel to get the functional structure of the application built and ready for the creative to be delivered and put into place. I think of this very similarly to figuring out the finishes and fixtures on the house while the (of course, very talented) construction crew builds the framework. There’s really no reason the two phases can’t work in tandem.

While in the examples the wireframes and comps are very rudimentary, you’ll see how if we work with an agreed-upon structure, development can build the framework on which the designers can create the aesthetic. Working in tandem helps with interactivity, as well. Collaborating closely on issues such as animations, click-behavior, colors, and the like, helps avoid re-work down the road.

Microsoft: “Oomph” — A Microformats Toolkit

Microsoft

Oomph: A Microformats Toolkit

 

 

Originally created in 2009 for Microsoft’s MIX Online, Oomph was designed with development by MIX Online’s Karsten Januszewski, who narrates this video overview. The goal of the project was to be able to provide a human-consumable conduit for what had been machine-readable information that was tagging people, dates, events, locations, and other information.

To help people access this embedded information more readily, we designed and developed a plug-in for browsers that would pull this content into an overlay on top of the page, parsing out and better visualizing the salient content for which the user was looking.

Downloaded and installed over 50,000 times, the Oomph plug-in helped foster better user-experiences and pushed the Microformats community to gain better penetration throughout the front-end web-design community.

It is currently available for download on the official Microformats site. Note, however, it has not been updated in a long time, and stability is not ensured.

Press

What’s so wonderful about the way the Oomph toolkit functions is that the useful data is all right there in the browser window. … By providing similar data in a specific format, it significantly decreases the effort necessary to extract that data, and then use it.
https://timkadlec.com/2008/10/microsoft-gives-microformats-a-little-oomph/

“Microformats are about enhancing the web, representing data in HTML and moving that data around. Oomph: A Microformats Toolkit is for web developers, designers and users, making it easier to create, consume, and style Microformats. Oomph makes consuming and producing content for the web just a little easier, more efficient, more fun. Now featuring Oomph2!”
https://blogs.msdn.microsoft.com/uberdemo/2009/08/25/oomph-a-microformats-toolkit/