Boxes and Arrows: Comments by Austin Govella

Austin Govella — Fri, 26 Jan 2007 14:52:18 GMT

I’d also like to see some of the thinking behind the new community features.

Austin Govella — Fri, 26 Jan 2007 14:52:18 GMT

Would this be a review? It might be more useful as a comparison between several packages.

Austin Govella — Fri, 26 Jan 2007 14:52:22 GMT

I agree with Donna, here. The idea is absolutely great. I’d love to read it.

At the same time, I agree that you cna leave it eneded, open a space for conversation, however, Donna’s right: if you don’t have your focus firmly nailed, it’ll end up too wishy-washy to be of any use, or to capture attention.

Austin Govella — Fri, 26 Jan 2007 14:52:22 GMT

I think it’s relevant. In my world (and I might be reading Wayne wrong) functional specs are driven by the research and synthesis part of the process.

Tracking the a design’s functional specifications is a headache. I’m constantly forgetting why one feature was omitted and another was included.

It’d be great if Wayne could offer some experience or a system for keeping them organized.

Austin Govella — Fri, 26 Jan 2007 14:52:22 GMT

But why is “apophenia” related to mental disorders? Makes me feel dirty.

Austin Govella — Fri, 26 Jan 2007 14:52:22 GMT

I think this would be amazing. I wish I could offer to help, but even if you could only provide a broad overview with jumping off points for the industrious, that would be a definite boon to the community.

Austin Govella — Fri, 26 Jan 2007 14:52:26 GMT

I agree with Dmitry about the Google Ads. And I’m not sure how much having them midway through the article will improve clickthrough.

I would enjoy related advertising on the homepage: ads for events, conferences, software, books, websites, etc.

Those kinds of ads would go along with my goals of visiting the site to keep up with the practice.

The overall design is excellent.

Austin Govella — Sun, 25 Apr 2010 08:42:50 GMT

Very nice explanation of how to conduct and use competitive landscape/analysis.

Could you amend the article by posting a sample document for others to see?

Austin Govella — Tue, 27 Jan 2009 01:15:08 GMT

Donna, exploratory and don’t know… seem like very similar behaviors. Is the distinction between the two simply that exploratory has no specific intent where don’t know’s have a fuzzy intent? Or is there a brighter line you’re drawing?

Austin Govella — Fri, 26 Jan 2007 14:52:48 GMT

So how do we reframe the issue so clients become disinterested in compliance and develop the interest in empowering both their clients, as well as themselves?

In a similar vein, how do we break the idea of accessibility away from disabilities and explain it as part of creating a cost-effective, loosely coupled client-side software system that preserves value for their enterprise architecture?

Austin Govella — Fri, 26 Jan 2007 14:52:48 GMT

Scott, I think this is true if you’re trying to sell Accessibility to the parent organization. However, if your accessibility becomes a byproduct of how you create interactive products (I’m thinking about the web here), then it’s just icing on the cake.

I was just re-reading one of Dan Brown’s old wireframe articles, and he had a catchy turn of phrase I think applies here: if people are fighting over pie, make a bigger pie.

In this sense, if they won’t buy accessibility, sell something they will buy where accessibility is just a part of the package.

Austin Govella — Fri, 07 Jan 2011 19:39:19 GMT

Awesome essay on students and masters, knowledge and wisdom.

Another much longer, but similar, book is Robert Bringhurt’s Elements of Typographic Style. The inclusion of best practices as well as clear discussions of the mechanics and history of typography make the book a tad heavy, but I wish there were books like these for all disciplines.

Austin Govella — Fri, 26 Jan 2007 14:53:02 GMT

This kicks ass. I don’t have any better words.

Very technical, but now we can evaluate the usability of our icons. Sweet!

Austin Govella — Mon, 25 Jun 2007 15:09:43 GMT

It’s true. The quality of the prototype affects the feedback you receive, but testing early on with lesser fidelity prototypes can be really valuable. Most teams should have a set of wireframe templates that leverage existing identity, visual styles, and common assets (like custom buttons, etc.). This is only really possible if you’re extending existing products. Working from these templates, the time to make your wireframes more “real” dissappears.

However, if the problem is users don’t understand the conceptual nature of the wireframe, this is as much to do with education and culture as it does wth the wireframe’s fidelity.

At the World Bank, user testing is fairly strongly embedded in the culture, and the usability guru does an excellent job of educating users as to what an HTML wireframe is, what it isn’t, and the purpose of the specific test. Users test both bare bones HTML wireframes as well as higher-fidelity, grayscale wireframes. The higher-fidelity wireframes had to be grayscaled because users believed color versions were work that had already been completed, and there’s a bias against critiquing already completed work.

A common reason for using lower-fidelity wireframes is that users may hesitate to provide the same feedback they would if they were presented “ideas” for the site.

At the other end of the spectrum, at Comcast Interactive, I’ve heard stories where hi-fidelity prototypes were interpreted as finished products by management who liked what they saw and mandated a launch.

The same education and culture issues come into play, but getting real is certainly not without its problems.

Ideally, your wireframe should be crafted with its use in mind. Documenting decisions for history or for feedback should create a different wireframe than one used for testing or another used for communicating design with the rest of the team.

Austin Govella — Thu, 23 Aug 2007 23:51:46 GMT

Alexander,

I look at web 2.0 form a slightly different persective that might be more useful to practitioners in a large enterprise: web 2.0 isn’t about letting users take over the experience; it’s about letting them *contribute* to the experience.

At a really broad level web 2.0 allows individual users the ability to contribute meta data to the network as a whole, or to specific resources. Web 2.0 applications harness user input to add greater clarity to network resources.

Input arrives through various methods: traffic, navigation, and search aggregation and analysis can provide most popular items, most popular searches, best bets, and related content.

If you allow specific user input like wikis, ratings, reviews, or tags, then this additional info can be used the same way. If it’s public to users on the system (e.g. all intranet users), then it has the possibility to provide more clarification and enrich existing resources for everyone on the system.

But if this information is private—visible only to the originating user, the author—then it still adds great value. Adding tagging for findability is a good example. Just because my tags aren’t shared doesn’t mean they won’t help me narrow a large collection into manageable chunks I can scan and browse.

In every large enterprise I’ve ever worked with, the biggest problem has always been improving the relevance of information that users found. Web 2.0’s focus on improving relevance by augmenting meta-data does just that.

Blogs, open APIs (for mashups) may not match your current culture, but helping users find better stuff faster is en vogue everywhere.

One of your last thoughts really struck me: how do you engender buy-in. If it’s designed correctly, you won’t have to. Employees all work different ways, generate value in different ways, and contribute to organizational knowledge in different ways. Some will write a memo. Some will file it on the network. And some will tag it so its easier to find. Not all employees have to participate in each activity.

User-generated content is icing on the cake. It doesn’t hurt the cake.