Lazyweb Request: An RIA Wireframing Service

Something just struck me–something that I’d really like to have. Can someone create an RIA that allows me to quickly create a low-fidelity sketch of a site, along with a service that allows these to be published, annotated, and shared online? Off the cuff, my base requirements for this would be:

• Multiple pages, with the ability to onion-skin them.
• Basic tools: shapes, lines, text. Of course, they need to remain editable constantly and, oh what the heck, allow me to push and pull them in front of one another.
• Online publishing — something like “share this site”
• Hyperlinks between pages
• Multiple authors and reviewers
• Secure login
• Site tree navigator
• Annotations, like callouts and speech bubbles
• Collapsible notes pane

Some really nice-to-have’s include:

• Multiple sites, with reusable components across them
• Multiple master pages
• A desktop client that can sync up to the site
• Versioning
• Export site to PDF

Maybe there’s something already out there that does the task? Adobe Version Cue has some collaboration tools that I haven’t yet explored. Gliffy does some of this too. Denim is close, but lacks a service to map up to.

Some of the tools that I think do a great job, and would serve as inspiration for this tool include:

• Skitch, because it seamlessly posts images to the web
• Gliffy, for its versioning, collaboration and nice drawing tools

Finally, while I’m at it (and since there’s still lots of time before Christmas), I want a image thumbnail web service. Basically, I send it an image and tell it what size and type of thumbnails I want. Perhaps I even supply it with the crop coordinates. It sends me back a gzipped file with my images. Oh I can wish.

Pidgin: wireframes for designers and developers

A few days ago, I wrote a post on the Capstrat blog about this idea I’ve been working out. It’s called Pidgin, which is a diagramming tool to accomplish two goals in tandem. One, Pidgin is aimed at providing definition to what a UI needs to encompass. Second–but in unison–it needs to be less prescriptive of the visual design. So basically, it’s trying to situate itself in the pre-design phase, when requirements are solid but the design is still fluffy and unbounded. Check it out here. Manners dictate that I don’t cross post.

The Stage: a shared, persistent space for persona development

At work, we’re always looking for ways to better bring personas to the creatives and the developers. One idea that we’ve been tossing around is a physical moodboard for personas. I’m calling this the Stage.

The Stage

The stage is a lo-fi, physical space where personas are built and refined. It is designed to evolve and to be a work in progress. Implemented, it resembles a mood board for personas.

Why are we doing this?

Carrying a deep respect for the user throughout a project’s development is critical to user experience design. Knowing who we are designing for is the responsibility of all project members. Much of the information known about the users is contained within the minds of the UX designers. The product– formal persona documents– often do not communicate the research and insights that underpin them. Often, they lack the vivacity needed for others to empathize with the users they represent. Further, they don’t easily engage other parties in the research and design process.

Much of the information that describes the user is secondary to the persona. Quotes, thoughts, misgivings, apprehensions help develop the persona but can be overly summarized to make a tight, succinct document.

Additionally, personas don’t easily invite serendipity and evolution. Research doesn’t stop once a persona document is delivered. As time progresses, inevitably designers better understand users’ behaviors and desires. The Stage invites these small bits of information in an unstructured way. It encourages discussion, change and evolution. Viewers are able to respond to these artifacts and discuss the inferences and conclusions that are drawn.

As a physical space, the Stage asserts itself and demands attention. Permanence and visibility are key to its success. It needs to occupy a space that receives constant foot traffic and where close inspection is encouraged. As a dedicated space, it invites asynchronous interaction where people can respond to it on their own time.

What does it need?

The Stage requires simple ingredients. Foremost is a space to place the material. It should be waist to chest high and (for us) at least 4’ x 4’. The surface should be a surface that can be written on: butcher paper, a whiteboard or similar. Nearby should be a steady supply of post it notes, markers and tape. Materials added to the Stage include screenshots, pictures, quotes, brief bios, research findings and diagrams.

A visitor should be able to glance at it and assemble an idea of the persona without reading a lengthy document. People may feel free to add and remove items from a persona as they see fit. Questions may be added to the board for other designers to react to. Generally, the Stage should resemble a work in progress; it should not appear overly structured or precious. Staying orderly and presentable can discourage others from adding their own input.

The Stage is not a replacement for personas. It exists as a shared sketchbook, the results of which are formalized into the persona documents. During the development cycle, it is a continual reference point for all members of the project team. For people outside the project—clients, visitors, for example—the Stage is a demonstration of user-centered design. It indicates how we involve the user in our approach and serves as a discussion point to further evangelize the need for understanding the user. Succinctly, the Stage helps make the research process more transparent.

Etymology

The name “stage” was borne of two ideas that are relevant to the concept. From theater, the stage connotes a place where characters are presented to an audience. The Stage can also be defined as an intermediate place where concepts are still being explored and refined. Both invoke the spirit and goals of the Stage.

oombrella is naked

Today, April 5th is CSS Naked Day. That means that the site you’re seeing today has been stripped of all css, rendering the site in all its non-styled glory. Why do this?

The main reason is to draw attention to the the underlying markup of a page, and to demonstrate how people with screenreaders might be seeing the site. In particular, it calls to attention the structure of the xhtml and the benefits of using semantic markup.

What’s Wrong
It’s been since dev that I have really looked at my site unstyled. I’m fairly pleased with how it renders but I’ve noticed a few problems that I want to mention.

1. Heading Images: I’ve used inline images to identify content areas such as “About Me” and “Design Portfolio”. As a designer, I wanted better control of the typeface in these areas. These would be better served using sIFR, but I didn’t want to hassle with the placing the extra javascript and flash into the page. Plus, I didn’t want to test for that in multiple browsers, so I took the easy way out. Unfortunately, is looks terrible when the page is non-styled and, of course, it’s less than accessible.
2. Structure: On the main page, the blog posts falls beneath the design portfolio. I would prefer this to appear first in the structure. The most “interesting” content on the site–as defined by google analytics–is the blog section. I think it would be better served by placing it before the portfolio.
3. Layout: I am a heavy, heavy user of floats. Sometimes these don’t degrade so nicely. For example, on the main page, the image “design portfolio” displays inline with the “see all >” navigation button. Looks bad, but not life-threatening. There are some other rendering issues, such as the duplicate “see all >” links that appear beneath the portfolio. I’ve definitely leaned heavily on the presentational css to distinguish content areas. I also committed a no-no by not using a semantic structure for my breadcrumb navigation. Shame on me.
4. Functionality: As I alluded to in the previous bullet, my presentational css was used to collect similar content and navigation together. This disintegrates a bit and it can be a challenge to know what a particular link does.

What’s Right
Overall, I think the presentation degrades decently. I don’t have any problem reading or navigating the site. But I’d really like to hear your opinions. So far, the good points that I see are:

1. Structure: Each section seems to clearly defined and the navigation remains intact. The site isn’t terribly content-dense or complex, which helps this a bit.
2. Functionality: The primary and secondary navigation fall into place at the top and are immediately presented to the visitor. This goes for the page header too. These two things help describe the page and provide an obvious means to move around the site.

There are probably a number of other things that are positive and negative about my design. Please voice your opinions because, well, my time is up and I have to go to work.

Smallr Apps

It seems everyone is heralding the arrival of smaller, more focused applications–often ones that are available online. Jon Udell, in an InfoWorld post, makes a comparison to Unix and its history of lightweight apps that do one thing, and do it well.

I want to agree with that comparison but there’s one nagging issue. Unix provides an environment where it is fairly trivial to assemble the pieces into something useful. For relatively literate users, there is a shallow hurdle to creating a novel script by piping output from one app to the input of another.

XML-based formats are providing us the groundwork (namely a readily parseable) way of sharing data all around. What is lacking is a environment to tie these together. Content aggregators and “paste-in” code widgets only superficially provide us with useful integration–and that’s usually only at the presentation layer. Developer APIs and Greasemonkey get us a bit further, as evidenced by the flurry of mashups, but still impose a steep learning curve on the user. In addition, these tend to require a lot of footwork and don’t lend themselves to creating one-off, disposable interfaces.

The small and focused unix apps owe much of their success to having a readily accessible means to chain them together and produce something more useful. The unix world has the data pipe: how could this metaphor be extended to these small online apps? How could we wire things together easily, and in ways not directly afforded by the widget creators and API developers?

I’m bullish on YubNub, a “social command line” for the web. It provides a relatively disposable method of working with content in a lightweight manner by hacking GET query strings. YubNub’s still in its formative stages so I can’t knock it for being a bit arcane to the average person. However, Lazyweb, I’m still searching for something like Apple’s Automator, which provides a set of prebuilt data query and transformation services in a “drag-and-chain” environment.