The XML Query Working Group and the XSL Working Group have jointly published an update to the Candidate Recommendation of XQuery and XPath Full Text 1.0, and to the companion Use Cases. The former defines the syntax and formal semantics of XQuery and XPath Full Text 1.0 which is a language that extends XQuery 1.0 and XPath 2.0 with full-text search capabilities. Learn more about the XML Activity.
The Mobile Web Initiative Test Suites Working Group has published the First Public Working Group Note of A Method for Writing Testable Conformance Requirements. This document presents a method for writing, marking-up, and analyzing conformance requirements in technical specifications that can help other Working Groups develop better specifications more quickly. Learn more about testing-related work in W3C.
W3C has published a report and full minutes of the Workshop on Access Control Application Scenarios, held in Luxembourg in November 2009. Participants from 17 organizations examined the current limitations of access control, privacy enhancement, distributed handling of access control, and other challenging use cases. eXtensible Access Control Markup Language (XACML) was a focus of the Workshop, though not the exclusive topic of conversation. The report summarizes the major "takeaways" from the Workshop, related to XACML semantics, "sticky" policies, and credentials-based access control. The OASIS XACML Technical Committee is expected to take up these topics. W3C's Policy Languages Interest Group (PLING) is expected to discuss data handling policies and the matching and triggering of events in the privacy context.
The SPARQL Working Group has published a First Public Working Draft of SPARQL 1.1 Property Paths, which defines a more succinct way to write parts of basic graph patterns and also extend matching of triple pattern to arbitrary length paths. The group also published six updates, listed below. The group seeks feedback on open issues in particular. Learn more about the Semantic Web.
Welcome the coverage, refresh this page or follow us on Twitter for live updates.
Recap: The technology seems quite impressive but not revolutionary, it's essentially a bigger iPhone with more processing power. We appreciate the engineering that was required to make this happen but the many issues that other tablet devices face (such as the on-screen keyboard) do not seem to have been resolved in any meaningful way. This is essentially a collection of new, finely crafted apps. The UI is very Apple but totally adapted to a tablet form-factor. Great work on that front but this is basically the iPhone OS and no sign of multi-tasking or camera. Would have loved a front facing one to video conference.
Screen seems to be getting rave reviews, very clear, very easy to read. Response speed seems fantastic too. "Gorgeous" is what we're hearing. So a great device for sure and definitely something that could be useful for when you can't use a laptop but it's still difficult for us to recommend this as a must-have item.
This feels like a futuristic device, especially because it is so responsive and thin but in the real world we don't see a huge need for it. The iPod made listening to digital music work and the iPhone was quite possibly the first real smart phone but this doesn't really seem to give us something that isn't handled adequately by existing devices in some form or another.
It really has the feel of a gadget, a great, beautiful, futuristic gadget but one nonetheless. Things may change as we get to play with the units in 2 months but for now even Steve hasn't managed to manufacture the need for this in my life.
11:35am - comment: And that's it. No new iPhone OS or iLife which were both expected by many today; and definitely no new iPhone with touch-sensitive casing. I think today will be remembered for all the things we didn't get. This leaves a lot of room for other tablets, especially e-ink, low-powered ones like the Kindle which just do the reading right. I think we can expect many iPad versions of iPhone apps which is great but it will be a surprise if the iPad sales are even anywhere close to those of iPods, iPhones or MacBooks. This feel more like the MacBook air which was cool and impressive but nothing more than a vanity product for Apple. We knew we would be either blown away or underwhelmed by today's announcement. Unfortunately it's the latter.
11:32am: "This is a magical device, at a breakthrough price." Not really and not really. The iPhone was all about those holy crap moments but this is just a bigger iPhone with a smaller potential market.
11:30am - comment: The fact that Apple has built a dock with a "real" keyboard shows that they don't have full confidence in their on-screen keyboard. If touch-based input was good enough they wouldn't have had to but it seems that even Apple can't solve that one. It's just an odd thing to hold unless you hold it with both hands or like a notepad, which means you'd need a (shock, horror) pen. After slamming the stylus repeatedly with the iPhone launch they weren't going to do that.
11:25am: Designer Yve talking about a "magical device" but seems like a lot of internet chatter seems underwhelmed. To be fair to Apple they didn't promise anything and most of the hype was generated by the same audience who now seems disappointed. Steve Job's reality distortion field is in full effect but not really delivering the wow moment we were expecting.
11:23am: Available in 60 days which should give you some time to save if you really feel there's a huge need in your life for a tablet. Hardware isn't at all innovative (but then the iPhone isn't a bad framework to base it on). Dock with keyboard allows you to rest the iPad and type without having to do thumb yoga.
11:18am: The price is $499 for the 16GB base-model (without 3G) which is not terribly expensive but a bit of a downer considering how much the 3G connectivity was just hyped. The minimum cost with with 3G is $629. They have 6 models of the thing at 16GB, 32GB and 64GB with or without 3G. No upgradable memory. Most expensive unit is $829 which takes it into the range of a decent notebook and even Apple's own MacBook.
11:16am - content: Do we NEED this? We seem to think there's definitely a "want" but not a "need". Looks like reading may be great. It may change the way I go to the bathroom however.
11:13am: 3G built in. $29.99/month for unlimited data in the US.
11:11am: Somehow data entry into spreadsheets using touch doesn't sound like the best idea. However, there's a place for the device in areas where you walk around and need to take notes like healthcare, stock-keeping, etc... Not really sexy but it's light and yet big enough to be useable. Still, expect to see this in hip boardrooms everywhere. We hear Jack Bauer may be using one in one of the later episodes of 24.
11:07am: Phil Shiller is demoing iWork. Looks great but once again as you would expect iWork to look if Apple designed it for a giant iPhone. Don't get me wrong, this is the most exciting looking tablet out there but it everyone here isn't running out to get one just yet. Tablets are a hard sell.
11:03am - comment: Twitter seems to be running slow under the load. Apple's marketing momentum seems unstoppable at this stage. The tablet hardware seems good but nothing groundbreaking. Apple is pushing the app design which we already know they're good at. At this stage this is not much more than a really large iPhone but there is definitely a market for it, at the right price. We're still worried that the keyboard will be hard to use as the tablet needs to be held in a way that makes typing difficult.
11:00am: After showing a very slick reading UI as well as the new bookstore they are now discussing iWork for the iPad. iWork includes Keynote (presentations), Pages (word processing) and Numbers (spreadsheets) and is essentially Apple's answer to Microsoft Office.
10:55am: Steve is back and done talking about third-party apps. Now's the time to talk about the Kindle or how Apple will attempt to beat them at their own game. Enter, iBook, a first-party reading app which looks as slick as is to be expected. The page looks like a page, the bookshelf like a bookshelf. Looks like it could be comfortable reading on this even though it isn't an e-ink screen.
10:50am: More apps -- painting app looks very impressive and useful for the doodlers out there. Interface feels organic and responsive. Need for Speed looks slick and quick. Games are being pushed a lot.
10:40am - comment: Reading on this could be the big selling point, the screen looks very crisp and browsing intuitive. The rest of the apps (e-mail, etc...) are handled well by iPhone and MacBooks. This together with the gaming could really sell this thing.
10:35am: New York Times looks just like the paper version with embedded videos. Columns, inset images, etc... Looks like there's still a future for DTP.
10:30am: Some tech info: it's half and inch thick, 1Ghz processor, 9.7 inch display, Wifi, Bluetooth, compass, accelerometer, 10 hours of battery life, 1 month stand-by. How much will this thing cost?
10:25am - comment: Everything that has been shown up to now looks pretty much as expected, even the tablet design which is basically a stretched iPhone. Buttons are bigger, font sizes have been adjusted. Videos look great, photos look great. Our guess is that it needs more to become a must-have device vs something that fits uncomfortably between your phone and notebook.
10:20am: Apps and more apps. E-mail, photos and browsing look slick and as you'd expect from Apple. Experience between iPhone and computer. iTunes looks nice and tweaked for the form-factor.
10:15am - comment: There was a "missing plug-in" box when Steve went to the NY Times website. No Flash it seems. Odd they let that slide. We're a bit underwhelmed, this looks like a big iPhone and the keyboard looks like it may be awkward to use.
10:05am: Steve is on stage. "Apple is the largest mobile device company in the world".
10:10am: It's called the iPad (as many suspected) and looks similar to an iPhone with that single button at the bottom, a relatively thick border. Think MacBook Pro without the keyboard. OS UI looks like a mixture of iPhone and Mac OS X.
The UK Government has unveiled its open data website, data.gov.uk, developed with the help of Tim Berners-Lee (W3C Director) and John Sheridan (Linked Data Lead for data.gov.uk and co-Chair of the W3C eGovernment Interest Group). Like data.gov in the United States, the UK site reflects a growing awareness inside and outside of government that standards-based open data is a key enabler of government services and a building block for new information services across government and industry. Additionally, this new site showcases Semantic Web and Linked Data technologies. Learn more about Publishing Open Government Data and eGovernment at W3C.
The Web Applications Working Group has published the First Public Working Draft of Uniform Messaging Policy, Level One. The Uniform Messaging Policy (UMP) enables cross-site messaging that avoids Cross-Site-Request-Forgery and similar attacks that abuse HTTP cookies and other credentials. For example, content from customer.example.org can safely specify requests to resources determined by service.example.com. Rather than restricting information retrieval to a single origin, as the Same Origin Policy almost does, the Uniform Messaging Policy supports origin independent messaging. Learn more about the Rich Web Client Activity.
Ronan demonstrates proper pie eating technique.
Ronan eats pie
The history of the visual design of user interfaces can be described as a gradual change towards more realism. As computers have become faster, designers have added increasingly realistic details such as color, 3D effects, shadows, translucency, and even simple physics. Some of these changes have helped usability. Shadows behind windows help us see which window is active. The physicality of the iPhone’s user interface makes the device more natural to use.
In other areas, the improvements are questionable at best. Graphical user interfaces are typically full of symbols. Most graphical elements you see on your screen are meant to stand for ideas or concepts. The little house on your desktop isn’t a little house, it’s "home." The eye isn’t an actual eye, it means "look at the selected element." The cog isn’t a cog, it means "click me to see available commands."
Details and realism can distract from these concepts. To explain this, I’ll take a page from Scott McCloud’s Understanding Comics, a book which should be required reading for all designers.
The image on the left is a face of a specific person. The image on the right is the concept "face;" it could be any person. When designing user interfaces, we rarely ever want to show a specific entity; typically, we want to convey an idea or a concept. Details can easily distract from that idea or concept.
At the same time, it’s obvious that some details are required. Too few details, and the user won’t recognize the idea at all.
The circle on the left clearly shows a face. The circle on the right isn’t recognizable as a face anymore.
Let’s look at a symbol we actually see in user interfaces, the home button. Typically, this button uses a little house as its symbol.
The thing on the left is a house. The thing on the right means "home." Somewhere between the two, the meaning switches from "a specific house" to "home as a concept." The more realistic something is, the harder it is to figure out the meaning. Again, if the image is simplified too much, it’s not clearly and immediately recognizable anymore.
The thing on the left is a home button. The thing on the right might as well be an arrow pointing up; or perhaps it’s the ⇧ key.
Let me explain this concept using an entirely unscientific graph:
People are confused by symbols if they have too many or too few details. They will recognize UI elements which are somewhere in the middle.
The trick is to figure out which details help users identify the UI element, and which details distract from its intended meaning. Some details help users figure out what they’re looking at and how they can interact with it; other details distract from the idea you’re trying to convey. They turn your interface element from a concept into a specific thing. Thus, if an interface element is too distinct from its real-life counterpart, it becomes too hard to recognize. On the other hand, if it is too realistic, people are unable to figure out that you’re trying to communicate an idea, and what idea that might be.
The button on the left is too realistic. The button on the right does not have enough details to be immediately recognizable as a button.
The same applies to these toggles. Shadows and gradients help the user figure out what he’s looking at and how to interact with it. Adding too many details, however, ends up being confusing. The toggle switch is no longer just a toggle switch that is part of a user interface, it is clearly recognizable as a photograph of a specific toggle switch; it loses its meaning. It’s no longer a symbol, it has become a specific thing.
There is at least one specific area where more details are good: application icons. You want your icon to depict one specific idea: your application.
Coda’s leaf isn’t a representation of the idea of a leaf; it’s a very specific leaf, the Coda leaf. Acorn’s acorn isn’t just any acorn, it’s the Acorn. Adding details moves these images from a generic concept towards a specific entity, and in the case of an application icon, this is exactly what you want.
Graphical user interfaces are full of symbols. Symbols need to be reduced to their essence. This helps avoid cluttering the user interface with meaningless distractions, and makes it easier for people to "read" the symbol and figure out the meaning of an interface element. Realistic details can get in the way of what you’re trying to communicate to your users.
The goal is not to make your user interface as realistic as possible. The goal is to add those details which help users identify what an element is, and how to interact with it, and to add no more than those details. UI elements are abstractions which convey concepts and ideas; they should retain only those details that are relevant to their purpose. UI elements are almost never representations of real things. Adding too much realism can cause confusion.
Thanks to Max Steenbergen and Cameron Kenley Hunt for helping me form a coherent opinion on this topic. The second house icon is from Dellustrations’s icon set "Dellipack".
This article was original posted on Lukas' blog, Ignore the Code.
They are between one and two weeks old in these photos.
Last weekend I sat on the Tube (the London Underground to international readers), Piccadilly line to be exact, heading into central London. A young man got on and sat down opposite me. He got out a little ASUS netbook, turned it on, and swiveled the lid to use it as a touchscreen. "Awesome," I thought, "he's got one of those cool touchscreen netbooks running Windows 7. I'd love one of those, it'd be so convenient."
I watched the man use the laptop for a while, as he tapped at the screen and used two fingers to scroll on a page. It looked ace—it looked simple. But soon the experience turned sour.
I watched as the man pulled a stylus out from the side of the computer and started to tap at the screen. I thought styluses had been banned by international law since the introduction of the iPhone nearly two and a half years ago. Still, if there are still some things that can't use the OS zoom function, then maybe a stylus has to be used.
I then received an even greater shock.
I watched in amazement as the man lifted up the screen to try and use the keyboard. Upside down. A CTRL + something command that was not present in the touchscreen menu.
Naturally, as a usability practitioner, I was horrified but continued to watch the bloke struggle. It took him five stabs and glances back at the screen to confirm the action was successful. By this time, the man looked thoroughly frustrated with his program's choice of shortcut. Soon after, he packed up his laptop and got off the train.
What seems to be the moral story is that no matter how advanced your OS is, the applications that you run can still scupper the experience, especially with tablets. There are two solutions to this problem:
Hopefully there's a third way: the Apple tablet way. We'll wait and see about that…
This article was originally published on Steve's blog.
The XML Schema Working Group invites implementation of the Candidate Recommendation of W3C XML Schema Definition Language (XSD): Component Designators. XML Schema: Component Designators defines a scheme for identifying XML Schema components as specified by XML Schema Part 1: Structures and XML Schema Part 2: Datatypes. Learn more about the Extensible Markup Language (XML) Activity.
The Media Annotations Working Group has published a Working Draft of Use Cases and Requirements for Ontology and API for Media Resource 1.0. This document specifies use cases and requirements as an input for the development of the "Ontology for Media Resource 1.0" and the "API for Media Resource 1.0". The ontology will be a simple ontology to support cross-community data integration of information related to media resources on the Web. The API will provide read access and potentially write access to media resources, relying on the definitions from the ontology. Learn more about the Video in the Web Activity.
The Cascading Style Sheets (CSS) Working Group has published a Last Call Working Draft of CSS Styling Attributes Level 1. Markup languages such as HTML and SVG provide a styling attribute on most elements, to hold a fragment of a style sheet that applies to those elements. One of the possible style sheet languages is CSS. This draft describes the syntax and interpretation of the CSS fragment that can be used in such styling attributes. Comments are welcome through 09 February. Learn more about the Style Activity.
The Device APIs and Policy Working Group has published the First Public Working Draft of Contacts API. This API provides access to the user???s address book from within a browser environment. Learn more about JavaScript interfaces developed in W3C.
Amazon posted an announcement of an upcoming beta SDK for developing "active content" for the Kindle. The announcement also describes the revenue-sharing scheme, and mechanisms for controlling bandwidth usage on Amazon's Whispernet.
Read Amazon's full announcement here.
I just noticed that YouTube has yet again updated it's video player. And to my surprise, this time it realy works and looks great!
All the icons are in the right places, plus they all make sense visualy.
Check it out here: http://www.youtube.com/watch?v=GTlm6dU2xHk
W3C is organizing a Workshop on the Next Steps for RDF around June 2010; we will announce the exact dates and location as soon as possible. Since its publication in 2004, the Resource Description Framework (RDF) has become the core architectural block of the Semantic Web. The standard is now widely deployed in terms of tools and applications. Due to this wide deployment, additional R&D activities, and the publication of newer standards (e.g., SPARQL, OWL, POWDER, and SKOS), a number of issues regarding RDF have come to the fore. Workshop articipants will discuss these issues and help determine whether it is time for a new version of RDF. W3C Membership is not required to participate in the Workshop, but each participant must be associated with an accepted position paper. The deadline for position papers is 29 March 2010; see the Call for Participation for more information. Updates (including the exact date and location of the Workshop) will be added to the Call for Participation and will be announced on the Semantic Web Activity News Blog.
The Web Applications Working Group has published the First Public Working Draft of Selectors API Level 2. Selectors, which are widely used in CSS, are patterns that match against elements in a tree structure. The Selectors API specification defines methods for retrieving Element nodes from the DOM by matching against a group of selectors, and for testing if a given element matches a particular selector. It is often desirable to perform DOM operations on a specific set of elements in a document. These methods simplify the process of acquiring and testing specific elements, especially compared with the more verbose techniques defined and used in the past. Learn more about the Rich Web Client Activity.
A few years ago, I took stock of several Apple patents that opened up new interaction possibilities by rethinking the ways people could provide input through multi-touch, virtual interface controls, new physical controls, sensors, and more. Several of these including the "multi touch mouse" (now released as the Magic Mouse) have made their way into shipping Apple products.
Yesterday, in anticipation of Apple's "latest creation," Patently Apple compiled a similar list of Apple patents that may see the light of day soon. Looking through their article and at several additional patents from Apple, I compiled a list of the new interaction design capabilities these patents cover. In aggregate, these interactions began to look like an integrated system for managing applications and content.
The overarching UI model is a set of contextual virtual interface elements with audible and haptic (perhaps) feedback that are accessed and manipulated through multiple input formats. That's a mouthful—let's break it down.
Virtual scroll wheels, slider bars, keyboards, dials, menus, and more are used to edit, manage, and input information on the screen. These controls are mostly shown overlaid or "floating" on top of content and applications. Some controls require specific touch gestures to be used and/or provide audible or tactile feedback when a user interacts with them. For example, a rotation gesture for virtual dials can be used to set volume and may include feedback when the limits of the dial are reached.
Included as part of the virtual controls are several forms of virtual keyboards and specifically a two-handed virtual keyboard that uses multipoint touch for input (deliberately called out as different from the iPod/iPhone texting keyboard).
These virtual interface controls can be associated with specific user modes like navigation, scrolling, data entry, display, etc. So a virtual scroll wheel or slider bar may be associated with a scroll mode. A keyboard or keypad may be associated with data entry mode, and so on.
Controls can also be specific to the application a user currently has running. So a floating virtual panel for iTunes could include the controls you'll use most often in the application like volume, playlist access, next song, etc.
Virtual controls can also be position sensitive. For example, selecting a song in iTunes could bring up specific controls for audio files with data associated with that file (e.g., title, artist, genre, etc.), or a page-turning gesture that allows you to move between pages of content could only be available at the bottom of the screen.
These virtual interface controls can be accessed through specific touch gestures or multi-touch inputs. For example, a virtual scroll wheel in iTunes could only appear when two fingers are placed on the touch screen as opposed to one finger. Additional fingers could be placed on the screen to modify or enhance the visible controls bringing up new interactions or information.
In fact, Apple has outlined a complete hand-based input system with "unprecedented integration of typing, resting, pointing, scrolling, 3D manipulation, and handwriting." The system can individually detect all ten fingers and separate palms on a person's hand, which allows it to detect resting of hands, measuring when a hand or fingers touches and leaves the surface, interpreting taps from one finger as mouse button clicks, but disregarding a tap from two fingers, and more.
The touch-sensitive areas that can accept this kind of input are not confined to the front or screen of a device. The back of a hardware device can also contain touch-sensitive areas that may be tapped, pressed, or slid to generate inputs.
Different hardware inputs can also bring up specific controls. Technologies that can recognize your thumb or fingerprints can be used as inputs for accessing virtual controls. Specifically, fingerprint patterns can be used to actually identify distinct fingers. This could then be used to display different functions depending on which finger is being used. Similarly, proximity sensors can detect when a hand is near a device and display the appropriate controls.
Apple has also proposed using object recognition, facial detection, and voice modulation as input.
Finally, haptic responses can be used to provide feedback to users when they interact with a series of virtual controls. Haptic display technologies allow a user to "feel" different surfaces as their finger moves across a touchscreen. For example, a display could include a virtual click wheel which vibrates at a different frequency at the center. Users could easily sense the difference and use the click wheel without having to look at it.
Together, these proposals outline an integrated interaction model of virtual "floating" controls that are specific to the mode or application the system is in. The controls are accessed and manipulated through touch-based gestures, combinations of mutli-touch inputs, and/or inputs detected through sensors. Users get haptic, audible, and visual feedback when using these input methods to interact with the system's set of virtual controls.
Needless to say, it will be interesting to see which of these proposals (if any) make their way into Apple's "latest creation" (tablet?) this month!
This article was syndicated from Luke Wroblewski's writings archive, Functioning Form.
Depending on what we focus on, our brains can be completely blind to obvious changes going on around us. This is called "change blindness," and it is unnerving when you observe it. Below are a few examples of this in action.
This first video is an experiment conducted at Harvard where 75% of the people in the test don't notice that the man in front of them has turned into a different person. This was conducted in a formal test setting. The people involved were interviewed after the experiment to better understand their perception of events.
This next video shows change blindness being used as more of a parlor trick. Magician Derren Brown exploits this blind spot in a much more dramatic way. Changing clothes, race, and gender doesn't seem to matter to these people on the street. This demonstration isn't as controlled, but is a lot of fun to watch.
The last video is an "Awareness Test" that has been around for a while. You can run this test on yourself and on others.
The concept of change blindness highlights a potential problem for UX professionals. Most of the time, user researchers and UX architects begin their research with specific goals in mind, and are focused on a specific aspect of the product. But with this focus comes the risk that they will be blind to other aspects of the user's experience. What are we failing to capture when observing people using the products we design? We need to reserve space in our work for uncovering those things that we don't know we don't know, and make it an official part of the process. We will observe more of the moonwalking bears that teach us valuable lessons about our users and our products.
Here are the newborns at three days old. The brown one is a boy; the white one is a girl.
The WebCGM Working Group has published a Proposed Recommendation of WebCGM 2.1. Computer Graphics Metafile (CGM) is an ISO standard, defined by ISO/IEC 8632:1999, for the interchange of 2D vector and mixed vector/raster graphics. WebCGM is a profile of CGM, which adds Web linking and is optimized for Web applications in technical illustration, electronic documentation, geophysical data visualization, and similar fields. WebCGM 2.1, refines and completes the features of the major WebCGM 2.0 release. WebCGM 2.0 added a DOM (API) specification for programmatic access to WebCGM objects, a specification of an XML Companion File (XCF) architecture, and extended the graphical and intelligent content of WebCGM 1.0. Comments are welcome through 31 January. Learn more about the Graphics Activity.
The Web Applications Working Group has published a Working Draft of Programmable HTTP Caching and Serving. This document defines APIs for off-line serving of requests to HTTP resources using static and dynamic responses. It extends the function of application caches defined in HTML5. Learn more about the Rich Web Client Activity.
The San Francisco Chronicle published an interesting article on Monday about how "Yahoo Labs has bolstered its ranks of social scientists, adding highly credentialed cognitive psychologists, economists and ethnographers from top universities around the world. At approximately 25 people, it's still the smallest group within the research division, but one of the fastest growing."
Highlights:
The recruitment effort reflects a growing realization at Yahoo, the second most popular U.S. online site and search engine, that computer science alone can't answer all the questions of the modern Web business. As the novelty of the Internet gives way, Yahoo and other 21st century media businesses are discovering they must understand what motivates humans to click and stick on certain features, ads and applications—and dismiss others out of hand.
It's encouraging that Yahoo Labs is "focused now on the benefit that computer technology provides to people, as opposed to focused on what technology can invent," said Len Shustek, an angel investor and chairman of the Computer History Museum in Mountain View.
For a company that provides such a mishmash of applications and features to generally low-sophistication users, aren't they arriving a bit late at this realization?
Chances are you've come in contact with a piece of flat-pack furniture from Ikea. You may even have put a shelf or desk together with the help of an allen wrench and a single-sheet instruction manual. Ikea has successfully innovated in pricing, logistics, packaging, and store layout to become a global phenomenon.
But the lesson we, the UX community, can learn from Ikea isn't directly related to their low prices, or making customers put products together themselves. Rather, the valuable lesson we can take from the self-assembly giant comes from an earlier point in a product's lifecycle: the design stage.
When it comes to design, Ikea is a price-first company. Sure, they pride themselves of their Scandinavian design and ingenuity, but above all else they want their products to be as affordable as possible. As a result, the target price for a product defines and constrains the product design, rather than the other way around. Instead of specifying a product and then determining how much it will cost, Ikea decides how much a product should cost and then designs it to fit within the cost constraint. In an interview with CNET, Ikea product developer June Deboehmler said, "When we decide about a product, we always start with the price... Then, what is the consumer need?"
To some this may seem like a counter-intuitive approach. But in actuality, creativity loves constraints. It may seem that a cost constraint would be burdensome to designers but in fact it helps focus and guide their work. Even if cost isn’t the leading constraint (as it is with Ikea), it’s always a critical constraint that should be factored into design.
But in the world of software and UX design, you seldom see projects where cost is treated as a primary, initial constraint. Instead, cost is treated as something that’s derived from scope. Foundational problems with scope, budgets, and constraints are a setup for failed projects and poor UX. But how can we all learn from Ikea in a way that makes sense to industry? We have defined four lessons that will guarantee smoother projects before they even start.
After they’ve outlined a product’s scope, most companies already have a strong sense of what they think the product should cost, or at the very least how much they can afford. But, in the majority of cases, rather than communicating both the scope and cost expectations to their vendor or internal development team, they withhold the cost information. This forces the development team to go through a complicated, error-prone process of trying to extrapolate a cost estimate from the scope. This is followed by a back-and-forth of discussion until the estimate comes into alignment with the original cost expectation. The cost expectation (or limit) was known all along but everyone has to participate in a ritual dance before it’s disclosed.
In most other settings, this practice would be considered dysfunctional, and an example of how poor trust and communication wastes time and money. But, oddly, it’s standard practice in software and Web development. If the cost expectation is fixed and present from the beginning—in other words, it is a primary constraint—why not simply let the development team know about it? Constraints give the team better understanding of what will be possible, reduces errors in their projections, and gets them working sooner.
Companies are generally wary of sharing their budget numbers upfront for fear of having the development team take advantage of their trust. Their concern is that the development team will charge the full amount in the budget even though the scope of the project should actually cost something less. But, in actual practice, this can't happen because the scope is never smaller than the budget. For innovative, UX-focused product and website development efforts, the project's requirements will always grow as large as the budget will allow—again, cost is the project's primary constraint. The entire course of a project always entails an ongoing negotiation between the stakeholders and the development team about how much work can reasonably be accomplished, and how many requirements can reasonably be fulfilled, before the budget runs out. This is true whether or not the budget is initially disclosed, and whether the project is charged fixed-bid or hourly, because of the weaknesses of upfront planning and the ambiguity inherent to scoping documentation. If the development team is aware of the real cost constraint from the outset, their projections about what they can accomplish will be much more accurate—and, often, much more ambitious—than if they were left to make guarded guesses about what the cost constraint might be.
Initial scope and specifications documents are a form of guesswork product design often done by whoever owns the project, rather than by actual product designers. Such documentation is meant to serve as the definitive blueprint for the project, but have you ever (seriously, ever in your life) seen an early scoping document that turned out to be anywhere close to accurate when the project was done? This isn't because the people drafting these documents are incompetent; it's just that product design is something best left to, well, product designers.
And even for the most experienced product design professionals, the beginning planning stages of a project are the time when the least is known about what the project will actually entail. This is the worst time to have to lay out definitive specifications for the product. Complex, UX-focused software projects just don't lend themselves to extensive upfront planning and specifications efforts—too much of the project's actual needs won't be discovered until design and development commence. So how, then, can project stakeholders ensure their vision and requirements for the product are met? By expressing their needs very clearly in terms of the business' goals for the product. Goals are another form of constraint.
When business stakeholders attempt to build detailed specifications up front, they are attempting to extrapolate specific requirements from their general goals. If Ikea took this approach in their product design, businesspeople would spend a week in a conference room trying to describe in words in long, numbered lists, exactly what a chair or table should look like and what features it should have. This would obviously be silly; product requirements (for both furniture and software) are best expressed through design materials and prototypes, not through lengthy specs built by business stakeholders. The stakeholders' role is to clearly express the constraining goals for the product and hand those off to product designers who can begin to design the specifics.
Business stakeholders need to ask themselves, what does it mean for a project to succeed? Is it successful if it fulfills on guesswork requirements built by the wrong people at the wrong time in the project, or is it successful if it meets the business' goals and stays within its budget constraints? Business stakeholders have the clearest understanding of what the company needs the product to accomplish, but the team that will build the product will advise them best on how to meet the goals. Setting clear, high-level goal and sharing the project's budgetary constraint gives a reliable development team the ability to plan accurately, reduce risk, and squeeze the most bang out of a buck.
As we mentioned, many companies refuse to share their budget out of worry that they'll be taken advantage of. If you tell a car salesman that you're willing to spend $30K, he'll try to sell you a $20K car for $30K. If, on the other hand, you keep your budget constraint to yourself, you may drive out with a $20K car and $10K in savings in your pocket. But when shopping for cars, you're dealing with products that have already been built, and you're just picking the one that suits you. But when you're building software or a website, you're building something entirely new with great uncertainty about, and flexibility in, the details of the implementation. The scope of the product is a direct function of its available budget.
It's critical that you be able to work honestly and openly with your development team or vendor. You'll collaboratively manage a project to ensure it fulfills its goals, stays within its cost constraint, and delivers the best value possible. If you don't think you can trust your development team or vendor enough to share your budget with them, then you're working with the wrong team. That lack of trust will undermine the success of the project by crippling your ability to collaborate effectively. You and the development team need to be partners in building a great product, not adversaries who are managing each other as risks. In an adversarial or arms-length relationship, the development team will always be trying to do the least amount of work for the most money. The business stakeholders, for their part, will be trying to take advantage of the ambiguities in the initial scoping documents to get the development team or vendor to do more work for the same price. Both parties will be focused on protecting their interests, rather than working as true partners toward the joint goal of a good outcome for the project.
This partnership with the design team is what Ikea achieves by staying goal- and cost-focused. While it's uncertain what the product will look like, it's never ambiguous what the definition of success is for that product. This business stakeholders and design team are working toward the same goals without needing to keep information from each other.
This guessing game of "what's my budget" is very much a waste of time. Some business stakeholders think they couldn't possibly guess what a project should cost, but in thinking this they're approaching the problem backwards. When it comes to important, high-complexity, UX focused software and website development efforts, the question isn't "what should this cost," but instead "what can this cost?" One needs to have a number in mind—a limit that will constrain the scope and ambitiousness of the project. Giving development teams a pile of guesswork specifications documentation will just get you a pile of guesswork price estimates. What you end up with are unreliable specifications and unreliable cost estimates. By providing development teams with a specific understanding of your cost constraints, you make it much easier for those teams to make accurate projections about what will be possible. This also lets development teams show you other projects from their portfolios that had similar budgets. This, in turn, allows everyone to work from a solid understanding of the cost constraint with a concrete example of achievable scope. Development teams can help stakeholders by providing detailed information about the budgets and challenges encountered in their portfolio projects.
We believe that these four lessons are important to succeed in the high-complexity domain UX-focused software and Web development. Making cost a primary constraint and sharing budgets with development teams may require a shift in thinking by all parties involved. Business stakeholders need to trust the teams they work with, and therefore choose to work with teams that are trustworthy. Development teams need to earn that trust by clearly communicating what they will do with the information and by being honest and transparent about their projections and about project progress once it's underway. And if there's any doubt on either side, you can always say, "Hey, it works for Ikea".
The W3C Advisory Committee has re-elected Ashok Malhotra (Oracle) and Henry Thompson (U. of Edinburgh) to the W3C Technical Architecture Group (TAG). Continuing TAG participants are John Kemp (Nokia), Larry Masinter (Adobe), T.V. Raman (Google). The Director is also expected to appoint three individuals very soon. The mission of the TAG is to build consensus around principles of Web architecture and to interpret and clarify these principles when necessary, to resolve issues involving general Web architecture brought to the TAG, and to help coordinate cross-technology architecture developments inside and outside W3C.
The Web Accessibility Initiative (WAI) Education and Outreach Working Group (EOWG) today published Contacting Organizations about Inaccessible Websites as part of the WAI-AGE Project. This new WAI resource guides you through telling organizations about accessibility barriers on their website. WAI would like to know how this resource works for you and how we can improve it. See the blog post: Take a few minutes to encourage web accessibility. Your voice counts. Learn about Accessibility and visit the WAI home page.
So Google has finally officially announced its very own Android-powered, $529 (unlocked), Snapdragon-powered phone. In a nutshell: it's very thin, very high resolution and very quick. TechCrunch provides in-depth coverage of the launch event and Michael Arrington seems positively enamoured by it.
The phone certainly seems capable and a joy to use (see the official google demo) but all that power and resolution comes at a price: battery life seems pretty poor, even for smart phone standards.
While Android still has a way to go to reach the iPhone's momentum (especially on the app front), one can safely say that Apple finally has some serious competition. Google releasing their own (albeit HTC-produced) phone means they control the experience and can set the benchmark for other Android phone makers.
As a user interface designer, one of the most exciting changes I've seen in last few years has been the growth of rich Internet applications. Although I designed many good standard Web applications, interactions and components have long been limited. It was like trying to build a Lego sculpture with only three shapes. To me, having a full range of Legos is necessary to meet the complex challenges of designing interfaces for RIAs.
I have to think much harder when I design rich interfaces than when I work on standard Web applicaitons. With the increased flexibility and more components comes a higher risk of making silly mistakes. If I use a component inappropriately, users can't figure out what to do, even though the components may look cool.
The purpose of this article is to help designers avoid mistakes and to help them choose (or design) components based on sound, fundamental principles of usability.
Before I get into that, let me explain what I mean by a component. A component is the most granular piece of an interface. For instance, a component might be something for a user to make a selection from a list, choose ranges, or to enter, edit, and view data. This would include drop-down lists, text entry boxes, sliders, editable text, and others. Sometimes components are called controls.
Selecting and using good components is a very important part of the design process. It would be easy to write a spec that says "drop-down list goes here," "editable data field goes here," but we need to do more than that. All drop-down lists are not created equal. Some are inherently usable, and others are terrible. Designers need to be mindful about how every component works—from how it displays on screen, what triggers it, what feedback it provides, and what happens when the user finishes an action. Designers shouldn't leave component selection to developers, and developers shouldn't assume their favorite component library is actually usable.
But back to usability. There are some fundamental principles of how human cognition works that can help us choose components and feel confident they'll be usable. Let's look at them.
Vision is our dominant sense (for those of us with reasonable eyesight) and we, as designers, rely heavily on users to visually notice, interpret, and understand our designs.
There are many interesting facts about vision that impact usability. Here are some important issues that will lead to better usability:
Why do I mention these facts when talking about interface design? Because they have everything to do with users seeing components on pages and noticing change. If people can't see something or see it change, they aren't going to be able to use it.
So when choosing components, here's a handy checklist:
Kayak.com uses contrast and change to attract visual attention to the "updating results" message.
Quickflix uses deep shadow to make this notification message pop-out.
Assuming users spot a component, the next important part of usability is to indicate tothe user in to what the component does. There are two concepts that help users figure out what to do with something: affordance and intuitiveness.
Affordance
Affordance is the attribute of an item that communicates what can be done with it. When effective, users should be able to figure out what to do with an item just by looking at it. For example, in the physical world, round door knobs are for turning, buttons are for pushing, and chairs are for sitting on. Online, shadows and highlights can make buttons pop (which helps users know they can be pushed), sliders look like they can be slid, and dials look like they can be turned.
Intuitiveness
Everyone says they want interfaces to be intuitive. The funny thing about intuitiveness is that an interface can't be intuitive—only people can be intuitive. Intuitiveness is also different to innateness (possessed at birth). Intuitiveness is about learned behavior and can be considered synonymous with the phrase "easy to learn."
Things that are easy to learn build on existing knowledge. As designers, we need to know something about our users' existing knowledge before we can design or choose a component that will be help them act intuitively. This knowledge may vary with the topic, perhaps on the user's experience with computers, or the user's overall exposure to the product.
Following the two key principles of affordance and intuitiveness, a usable component will be one that:
When you open the geolocator on etsy.com, the globe is spinning slowly—a visual indicator that it can be spun.
This menu looks, feels, and works in a similar way to a Microsoft Windows menu, suggesting familiarity.
This drop-down looks like plain text, not like a drop-down menu. People won't understand what to do with it.
This component breaks convention. Checkboxes are for multiple selections, not for toggling pairs of items.
Another important part of usability is feedback. As users work with an interface or with components, they need to receive clear, helpful feedback about their actions. All feedback must be plainly visible, and must happen where the user is looking.
Feedback can take many forms, including (but not limited to):
Progress indicators help people know something is happening.
Twitter provides immediate feedback after clicking the "follow" button.
The MSN password strength component provides immediate feedback as you set your password.
Error management has always been an important part of interface design, and it is even more important when designing interfaces for rich Internet applications.
There are three aspects to error management:
The overarching goal is to help people avoid errors in the first place. Much of this can be accomplished with good task flow, layout, and labeling. But choosing the right components is a very big factor in error management. For example:
Date pickers help users avoid errors in format and date entry.
This button has help text so users can readily understand the consequence of an action.
Amazon's auto-complete functionality helps users avoid spelling errors.
Todoist's forgiving format allows users to enter the date how they want, not how the system demands.
When designing or selecting components, use this checklist to make sure every component in the interface will be usable. If you do, your work will make users happy, and that is your goal as a designer.
This article was originally published on the User Interface Resource Center (UIRC). For more info, please see http://uxmag.com/uirc
The XML Processing Model Working Group has published a Last Call Working Draft of XProc: An XML Pipeline Language, a language for describing operations to be performed on XML documents. A pipeline consists of steps. Like pipelines, steps take zero or more XML documents as their inputs and produce zero or more XML documents as their outputs. The inputs of a step come from the web, from the pipeline document, from the inputs to the pipeline itself, or from the outputs of other steps in the pipeline. The outputs from a step are consumed by other steps, are outputs of the pipeline as a whole, or are discarded. Comments are welcome through 02 February. Learn more about the Extensible Markup Language (XML) Activity.
The Web Applications Working Group has published a Working Draft of Indexed Database API. User agents need to store large numbers of objects locally in order to satisfy off-line data requirements of Web applications. The Web Storage specification is useful for storing pairs of keys and their corresponding values. However, it does not provide in-order retrieval of keys, efficient searching over values, or storage of duplicate values for a key. The current specification provides a concrete API to perform advanced key-value data management that is at the heart of most sophisticated query processors. It does so by using transactional databases to store keys and their corresponding values (one or more per key), and providing a means of traversing keys in a deterministic order. Learn more about the Rich Web Client Activity.
Now this is pretty interesting. Microsoft has filed a patent for muscle-based control interface that essentially allows you to control computers or mobile devices using your muscles' electical activity. This video demo shows some pretty interesting implementations. There's nothing quite like seeing someone play Guitar Hero without the guitar. Air Guitar Hero?
If you're in or near Austin, Texas, we recommend you check this out:
Practice user experience and interaction design with your peers
Design practice, January 4th, 7pm, Genuine Joe Coffeehouse
Are you a UX, IA, UI, IxD, usability, visual or other sort of designer in Austin, TX? Come out for a design practice workshop on January 4th, from 7–9pm, at Genuine Joe Coffeehouse (it’s on Anderson Lane near the Alamo Drafthouse Village). We’ll be doing the brainstorming practice exercise. Come a little early to get settled and get some coffee or a snack so we can start on time. I’ll be there at 6:30pm to set up if you’d like to introduce yourself or discuss the meeting itself. Paper, markers and other materials will be provided.
Check out the event website for more details.
Here is what one match will do to your Christmas tree. It took about a minute to go up and die back down, leaving only a smoldering trunk.
