I know the Aqua buttons are hi-fi, but they're useful when you're mimicking OS windows occasionally, e.g. pop up browser windows, JavaScript alert windows, etc.
I sent feedback to OmniGroup requesting that they add jitter/squiggle line stroke styles to the next release of OmniGraffle. Omni responded that they will add this request to an existing request for hand-drawn effects, but that feature requests usually make it to the product development team when there is enough clamoring for the feature. So if this is something you're interested in, send them feedback via their support page (scroll to bottom of page for email address.
Here's the feature request I sent:
I've been hearing a lot of people asking
for some way to make drawings created in OmniGraffle appear to be have
an unfinished look by simulating hand-drawn lines. A lot of people get
by doing squiggly lines in CAD or other drawing programs. But we've
also seen people use Visio to do this.
What would be ideal for Graffle is if we could have a stroke option
that simulates squiggly or jitter line effects in a future release.
Please consider this a vote from the many of us who are asking how to
do this on the design mailing lists.
* New callout styles added
* New forms elements added: contextual help, captcha
* Tabs and controls added
* Some commonly used icons have been added
I think I will have more of the icons to come, and may eventually separate the icons from the wireframe stencil if there ends up being too many. Since the set is small for now, I'm keeping it in this document.
Traction® TeamPage5™ is a free version of Traction Software's award winning TeamPage™ Server product. TeamPage5 supports up to 5 projects (blog / wiki spaces) and 5 named user accounts with individually defined permissions and identities. Projects can also be opened to Visitors (e.g. you can open any space so that anyone on your intranet can read, edit, comment or post). Registration for TeamPage5 provides a personal account on our support server to download software updates, read customer and product FAQ's, and participate in Traction's customer Forum.
Traction® TeamPage5™ is simple to download, install and manage. TeamPage software can be deployed on your intranet, corporate DMZ or on the public internet using a computer that supports Java server software, see TeamPage System Requirements. TeamPage5 provides a free way to create a collaborative communication hub which can scale to meet your future needs. You can easily upgrade to TeamPage15 or TeamPage at any time.
Excellent news for enterprises and now even individuals who are ready to take their knowledge management work to the next level.
I had an interesting conversation with a family member this weekend. This person is in an older category range--to 65 year olds nearing retirement. He happens to watch a few reality shows, one of which is "Dancing with the Stars", and we got onto the topic of judging on all of the shows with the "American Idol" format of judging.
From what we could gather, there seems to be 3 formats of judging:
The public call in and online vote method--used on American Idol
The expert judge method--used on Project Runway
The split judge/public vote method--used on Dancing with the Stars
The peer system where winners vote off another player--used on Survivor
The pure judge only option is not without controversy, as many who watched the 2nd season of Project Runway will attest to. Quality is a subjective thing to measure. The judges + call in vote system seems to be the one that tries to prevent the popularity of a public vote from being a way to game the system, and ensures that actual quality of performance has something to do with the outcome.
There might be others that I'm not aware of. These seem to be the most popular. Let me know if you are aware of others used on these reality shows.
Compare these with the systems used on social software sites.
For ratings, there's the purely quantitative rating system--used on Netflix
For comments there's the karma moderation system--used on slashdot and digg to promote or bury posts and comments
What are the methods and typical algorithms for both ratings and comments that prevent gaming these systems?
After over 8 wonderful years at Lucent Technologies, I have finally decided to move on. Over the past few months a few really terrific opportunities presented themselves to me, and I have decided to go to work for Sling Media to help start up the Sling Entertainment Group. This new group was created to design the web experience for the Clip N Sling technology that was announced at CES last December. I'm coming on as the information architect. A very talented team is putting this group together, so I'm very excited for what's to come.
I expect that I'll continue to blog about information architecture and interaction design, but the frequency and volume of my blogging is likely to diminish. I tend to write long blog entries, but can't see how I'll maintain that pattern given the change in work and lifestyle I expect. But do look for a wider array of topics to be covered, including web video.
As I've mentioned in a previous entry, I am no longer providing consulting services. On to new things!
I've been absorbing little bits on storytelling over the years to learn to communicate design more effectively. I was taking a comic book class and started reading Manga comics as part of this pursuit, which you might have read about here. And while that helps me in terms of finding new ways of visualizing the effectiveness of documents, it doesn't help with communicating messages face to face or with spoken words.
Tina pointed to this entry in Presentation Zen featuring Ira Glass giving Tips on Storytelling. Fans of Glass' public radio show, This American Life (now also a TV show) know how the experience of hearing a story can be as immersive and engaging as anything you can watch or read. Audio, in many ways, may be even more immersive than TV. Like literature, it demands that a good deal of the experience is stitched together or imagined in the mind rather than having everything explicitly depicted with visuals. Adam Curry often calls the experience "The Cinema of the Mind," referring to some of the immersive aural experiences in walking tour podcasts. But what we as designers can take away from Glass' interview in the video below is the pattern or recipe for telling the story.
Here's the recipe with bits paraphrased from Presentation Zen:
1. Find the anecdote or sequence of actions or events that tell a story rather than provide disjointed "facts".
2. Raise questions. Provide the "bait" with the implication that you will be answering them.
3. Insert moments of reflection at points during the story—a good way to do this is by reflecting on key points between anecdotes.
That's not all there is to it, obviously. He riffs a little on the problem of finding the right or most interesting stories. Sometimes the anecdote can be wonderful, but there may be no reason to care. Experience, and the ability to be ruthless, choose the right stories, and abandon the crap makes the difference here.
The crap, in Glass' case might be a boring story, or even an interesting one perhaps that just doesn't have any importance. But when it comes to telling the stories for our projects we don't have the option of abandoning the story because it seems boring on the surface. For example, communicating design concepts viewed from the standpoint of our personas might not seem very exciting on the surface. So the question becomes, how do we make it interesting. How do we communicate the story so that the rest of the team is interested enough to mentally engage with the characters and hold them in memory long enough to use them as a motivating factor in design.
Deciding to use storytelling as the vehicle is the first step in engaging the team, I would think. The analogy I would make here is that the document delivered rich with facts and data is akin to that high school essay that Glass speaks of, where a presentation or set of documents that immerse the team in the experience of the characters is more like the engaging and well told story.
The obvious next step is figuring out how you are going to use the pattern above to make telling the story, or communicating the experience effective and engaging. I'm not prescribing a formula for that because I'm always learning how to do it better myself. I've done some things in documents that use storytelling a bit, but the real deal for me is approaching each delivery as a pitch or presentation and taking the time to work on the delivery. While Glass' recipe above is general enough to be universal, the delivery is often very different depending on the story being told, but it's worth it every time to invest some time in tailoring it to fit.
I actually was playing with making an origami business card holder for those moo cards you see in the middle photo. While playing with some paper folding, ended up making an origami notebook instead, and slid the moo cards into the side pocket.
The notebook is a design I took from one of my origami books (Origami: The Art of Paper Folding by Gay Merrill Gross). I used a faux aligator skin textured paper for the cover and the pages are accordian folded.
I've actually been toting this along with me for my daily todo lists--as an adjunct tickler to the many 3x5 index cards that sit in my Action folder.
InfoWorld has announced the 2007 Technology of the Year Awards for the applications they rated best and most innovative in each of 8 classes of information technology. Traction Software, who I began doing user experience consulting for last spring, won in the Data Management category for Best Enterprise Wiki.
Last year, Traction released version 3.7 of Traction TeamPage and Communicator, which introduced several very exciting new content management and theming enhancements and continued to focus on usability improvements. If you're in the market for an application that does enterprise collaboration tool the way you want to, you'll want to check out the Traction 3.7 feature set.
Congrats to all the recipients of the IW Technology of the Year Awards.
Luke Wrobleski has written a great article discussing the difference between perceived and actual simplicity and what it means to designers. Simplicity is more than the perception of spareness or bareness of design. In actuality, simplicity probably has more to do with ease of use than with appearance, and achieving simplicity can be a complex task.
Wrobleski illustrates the Pareto principle applied to expert user features on sites like eBay and You Tube. On those sites 80% of activity comes from perhaps 20% of the users. These are often the expert users, who want to do more than simply find products or watch an occassional movie. Those users are the one's that add the most value to the system, so features that enable those users to be empowered need to be addressed. So how does that user type's need impact simplicity of the experience for others?
Tufte speaks of information density, how much screen real estate is devoted to useful information, as a measure of an information object's effectiveness at communicating messages. "Usefulness" is the operative word there. Data dense interfaces don't necessarily lead to ease of use. The point is that if the ratio of useful data to chart junk is good, the object has better information density. It is the usefulness of the interface for helping users get things done is what leads to actual simplicity.
Achieving a simple experience when the spectrum of needs of users are varied is complicated, but possible. He points out that some interfaces have tried to balance those needs, e.g. Microsoft Office's partially hidden menus. I don't know many people that would argue that the MS menu design has lead to a simplified experience.
The implication is that you probably want to find a way to make expert-enabling features available because they probably serve that 80% of value to your product or service. Making those features available is what makes the experience simple for those users. But how to do it? One suggestion in the comments is practical and probably generizable for most web sites. Michael Zuschlag writes:
I think the answer is that, while experts do use expert features, even they rarely use them. Most of the time expert features are a distraction even for experts. That doesn’t necessarily mean designers must eliminate or hide expert features, but it does suggest that designs should be proportional, with commonly used features easy to see and select, and rarely used expert features being less obtrusive, even if less convenient.
Sound simple enough? The proof, I suppose, is when the executed design is deemed useful to the types of users it serves.