user’s data is naturally something other than tables and if simulating his natural data model on top of tables is awkward, then chances are that a native implementation of the natural data model will significantly outperform a conventional relational DBMS. This is certainly true in scientific data.

A different implementation of tables. If something other than a row store accelerates the user’s queries, then a direct implementation of the relational model using non-row store technology will run circles around a conventional relational DBMS. This is true in the data warehouse marketplace.

A different implementation of transactions. Current row stores give you a “one size fits all” implementation of transactions. This can be radically beaten if a user has lesser requirements or if the system can take advantage of workload-specific features. This is true in the OLTP marketplace.

One of these characteristics is true in every market I can think of. Hence, in my opinion, the days of a “one size fits all” monolithic DBMS are at an end. The replacement will be a collection of vertical market-specific engines, with much higher performance.

You might ask, “What if I don’t care about performance?” The answer: Run one of the open source relational DBMSs. They are mature, reliable, and, best of all, free.

You might also ask, “I am dug in deep with my current vendor(s). What do I do?” The answer: Take some portion of your DBMS budget and allocate it to new solutions. Over time, you will move onto better technology.

It is very true that relational DBMSs are overhyped for not so valid reasons. The current trends also showcase that there are viable alternatives to relational DBMSs, which can beat them at their own game. Also, the emergence of distributed key-value stores, such as Cassandra and Voldemort, proves the efficiency and cost effectiveness of their approaches.

Also, the recently concluded NoSQL conference discussed at length how distributed, non-relational databases work, along with overview of the emerging alternatives in this space.

Pavan Yara —

from Jason hong’s “Designing effective interfaces for usable Privacy and Security”

I often cringe when I hear highly technical engineers talk about people.

I usually hear broad generalizations tossed about, like “people are lazy, that’s why they can’t use the system” or “people don’t understand security.” The worst is “people are just stupid.”

With this kind of attitude, it’s no surprise there are so many complicated user interfaces in the world, let alone in privacy and security. Failing to try to understand things from the user’s point of view is the cardinal sin in user interface design.

With this in mind, I thought it would be good to shift focus in this blog entry away from individual case studies of usable privacy and security, and look at the bigger picture of how to design better user interfaces.

Now, how to craft an effective user interface is a very involved topic that one can study for years, and there are lots of great Web sites and books out there. Effective user interface design combines our understanding of aesthetics, technology, and human behavior to develop artifacts that are useful, usable, and desirable for a specific target audience.

What makes usable privacy and security different from designing other interfaces is that privacy and security are often secondary tasks. People don’t go to an e-commerce site explicitly wanting to protect their credit cards and email addresses; they go there to buy things. Security and privacy are obvious things they want while accomplishing their main goal, in the same manner that they want the Web site to also be fast and usable.

Roughly, there are three broad strategies for usable privacy and security (note that these aren’t mutually exclusive):

make the interface invisible ˲ make the interface more under- ˲

standable train the users ˲

A good example of better security by making the interface invisible is Secure Sockets Layer. End users don’t have to do anything special, and all

of their network traffic is transparently encrypted.

Oftentimes, we just need to make the user interface more understandable to end users. This might be accomplished through better layout, simplified task flows, better visualizations, or more appropriate metaphors (why do we sign digital documents using keys, anyway?).

Finally, some user interfaces may also require training the users. One common misconception about user interfaces is that they should be “ intuitive” (a description that always raises a red flag with me). If you’re a Star Trek fan like I am, you might remember that famous scene in Star Trek IV where Montgomery Scott, the ship’s engineer, tries to use a Macintosh computer. After attempting to talk to the computer and getting no response, he picks up the mouse and tries talking into it. Intuitive indeed.

Applications are always designed for a specific context, for specific purposes, and for a specific target audience. The best designs will empower people and let them get started quickly, while also providing a way for them to get better.

As such, some applications will require some level of training. The training might range from a basic understanding of how to zoom in and out on the iPhone (which Apple cleverly trained people how to do, with their television ads), all the way to learning how to drive a car (something we actually start training our children to do since birth, given how ingrained cars are in society).

Now, this doesn’t mean that you can get away with a disastrous user interface and expect people to have to train how to use it, but it also doesn’t mean that all user interfaces should be walk up and use either. You have to balance ease-of-use with power and flexibility for your specific audience and your specific goals. As Silicon Valley pioneer Doug Engelbart once noted, if ease of use was all that mattered, we’d all still be riding tricycles.

 

Michael Stonebraker is an adjunct professor at the Massachusetts Institute of Technology. Jason hong is an assistant professor at Carnegie Mellon University.