Upon logging in and creating a “blist”, you are presented with a spreadsheet-like view. You then drag and drop data types onto the spreadsheet to create columns.

“Lenses” can be created to get non-tabular (and filtered) views of your data. Data can be entered directly both in the table or in the “lense” views. There are options to share and discuss “blists” — however these don’t seem to be implemented yet.

Blist is still in a very early stage. Following are some comments, based on my initial impression.

Neat!

In addition to the standard data types (text, numbers, dates etc) there are lots of unusual but useful data types such as email addresses, images, and star ratings.

Columns (unlike in a normal spreadsheet) can be set to allow multiple values in a single “cell” (possible, but cumbersome to implement with a normal database).

You can easily create “custom types” a.k.a. “pick lists” or enumerations.

It is possible to group/nest columns one level deep, creating a “blist-in-a-blist”.

Blist (unlike a normal database) doesn’t prevent invalid values in fields that expect a certain format. But (unlike a normal spreadsheet) invalid values are highlighted.

Suggestions…

If non-technical users are the main audience, it may be worth thinking about making the interface less intimidating. Too many buttons and controls!

Features that haven’t been implemented yet would probably better be hidden from view. It’s frustrating to not know if a button is disabled because you’re in the wrong mode, or because it isn’t implemented yet…

Support for undoing actions (and fewer prompts).

Support for changing the data type of a column (e.g. from number to string).

There is a nice calendar control for entering dates. Unfortunately it can’t be bypassed — if you want to enter an old date you need to go back in time month by month… The money data type is nice, too, but seems to be USD only.

Some of the data types muddle the distinction between data type and display. For example, is a checkbox really a different data type than a boolean — or is it just another way to display boolean values?

Help, Firefox eats all my memory! (May be an issue with Flash?)

I bet a geo-location data type and map view is already being worked on…

If the query builder showed a preview of the results, this would save some tedious back and forth when building queries. Speaking of search: Where is the quick search?

Should be able to link blists to each other (one of the killer features of relational databases)!

Support copy-pasting single (and multiple) cells.

Finally, there is a typo in the “downloading Lenss” status message :-)

Conclusion

While Blist isn’t the first effort to do spreadsheets or databases on the Web (think Google Spreadsheet or Freebase), the way it combines the best features from both worlds seems new (to me, at least).

Will be interesting to see how the “social” features are implemented — and of course if their infrastructure manages to scale (especially once they enable the data import feature and people start dumping existing collections into Blist)!

After going through all the different terms that people use when talking about data (some of these terms have fallen out of fashion, others are still in use), Kent points out inconsistencies and limitations of the relational and hierarchical data models:

the data processing community has evolved a number of models in which to express descriptions of reality. These models are highly structured, rigid, and simplistic, being amenable to economic processing by computer. [...] Some members of that community have been so overwhelmed by the success of a certain technology for processing data that they have confused this technology with the natural semantics of information.

Of course Kent is full of understanding for those poor, misguided souls:

The builders and users of today’s commercial systems quite justifiably want to avoid cluttering their systems with anything that may impair efficiency and productivity. The argument that this new approach will make the overall management of data more productive in the long run has yet to be convincingly demonstrated to them.

He predicts that data integration will be the killer application for a more sophisticated data model:

The need for a more descriptive model will only gradually achieve general recognition. It will come from the headaches of trying to crunch together the diverse formats and data structures used by growing families of applications operating on the same integrated data base.

Kent then goes on to outline an ideal data model (graph-based). Nevertheless he manages to remain realistic:

Perhaps it is inevitable that tools and theories never quite match. There are some opposite qualities inherent in them. [...] Thus the truth of things may be this: useful things get done by tools which are an amalgam of fragments and theories. Those are the kinds of tools whose production and maintenance expense can be justified. Theories are helpful to gain understanding, which may lead to the better design of better tools.

In the long run, simple style with quality construction and efficient performance wins. So a business that [creates] web sites for shipping, commerce, or information, would be wise to stick to the fundamentals. [...] Only for products whose goal is “entertainment, or style, or perhaps enhancement of a personal image” does fashion come into play. The design moust match the target audience and “it is probably necessary to have multiple versions of the design for different market segments” and “rapid changes in style and appearance” are required.

Three levels of design are distinguished:

1. visceral
2. behavorial
3. reflective

Visceral design:

People are often willing to overlook shortcomings if a product is pleasant to use.

The visceral level is the “look and feel” that makes people want to own your product, regardless of whether they need it or not.

Behavorial design:

At the behavorial level “appearance doesn’t really matter [...] performance does”. Design at this level means talking into consideration not only function, but also understandability and usability.

First, it is important to recognize that

tasks and activities are not well supported by isolated features

so check-list based development won’t do – you need to understand just how people will use a product.

There are two kinds of product development: evolution and innovation.

Asking potential customers for their views is not an effective way to innovate:

Focus groups, questionnaires, and surveys are poor tools for learning about behavior, for they are divorced from actual use. Most behavior is subconcious and what people actually do can be quite different from what they think they do. We humans like to think that we know why we act as we do, but we don’t, however much we like to explain our actions.

People have said they would really like some products that have failed in the marketplace. Similarly, they have said they were simply not interested in products that went on to become huge market successes.

Evolutionary development, too, is best done by watching people, as “people find it difficult to articulate their real problems”. Also, many people blame themselves for problems they have.

Regarding usability:

[The product] should not require years of dedicated practice. New items appear every week, but who has time or energy to spend the time required to learn each one? Bad design is a frequent cause of error, often unfairly blamed on users

designing for the handicapped, the hard of hearing or seeing, or those less agile than average invariably makes an object better for everyone.

Why do so many designs fail?

• Engineers tend to focus upon technology, putting into a product whatever special features they themselves prefer.
• Designers like to make sophisticated use of images and metaphers that win prizes in design compititions but create products that inaccessible to users.
• Managers focus upon making sure that each division in a company receives the recognition its political power deserves.

Good behavorial design has to be a fundamental part of the design process from the very start; it cannot be adopted once the product has been completed.

Therefore it is

important to have a rapid, iterative development process. The prototype is tested with users right from the beginning.

Reflective design:

This is a more subtle level of design that not all people may be able to appreciate – much like good movies…

The best designs come from following a cohesive theme throughout, with a clear vision and focus. Usually, such designs are driven by the vision of one person.

If you want a successful product, test and revise. If you want a great product, one that can change the world, let it be done by someone with a clear vision. The latter presents more financial risk, but it is the only path to greatness.

Another issue is customization, which the author invariably fails to find useful:

The things I really want to customize [...] can’t be customized. [...]

If something is so complex that it requires the addition of multiple “preferences” it is probably too complex to use.

Proper customization comes through combining multiple simple pieces. I don’t customize my pen; I do customize how I use it.

The main purpose of visualization is to help people detect patterns – though the author cautions that people are quite capable of seeing patterns where there are none… The author also cautions against overuse of visual techniques:

Natural language is the most elaborate, complete and widely shared system of symbols that we have available. For this reason alone, it is only when there is a clear advantage that visual techniques are preferred.

Some practical advice extracted from the book.

• Don’t use grayscale values to color categories in a graph.
• Blue areas focus behind red areas, for most people. This can be used to create an illusion of depth. It can also be used to make text unreadable…
• Colors allow an additional three dimensions to be visualized (rgb!)
• Fast movements or sudden appearance of items in the visual periphery attract attention – which may or may not be intended.
• Multi-dimensional, discrete data can be encoded by spatial position of a “glyph”, color, shape, orientation, texture, motion or frequency (e.g. blinking).
• Items can be associated visually by making use of proximity, similarity (see previous point), symmetric or continuous arrangement, or enclosure (e.g. in windows or Venn-diagrams).
• Animation can be useful though “the kinds of animated critters that are starting to crawl and hop over web pages are often unnecessary and distracting. Just as elegance is a virtue in static diagrams, so it is in diagrams that use animation.”
• People are poor at remembering images, but good at recognizing previously seen images.
• Large collections of images can be scanned faster by flashing the images in rapid succession (up to 16 images/s) than by looking through thumbnails (requires refocussing, only 3-4 images/s).
• Display numbers in an object view rather than in tables, if there is a natural or metaphorical mapping to a physical object.
• For displaying 3D surfaces use a single light source that is located above (the brain assumes this!), at an infinite distance. Make shadows soft, and use textures.
• Using three dimensions may increase the maximum complexity in a tree or graph that can be understood.
• Most people get sick in virtual reality simulators when they move their head from side to side while moving.
• Flowcharts are less suitable than natural language or pseudocode for helping people understand processes, because they require the brain to perform an additional translation step.
• Diagrams on the other hand can help people understand relationships.
• Data input always has a speed-accuracy trade off. This means that applications that are tolerant of small errors allow people to work faster.

How to motivate people to contribute to your project?

People should feel that their connection to a project, and influence over it, is directly proportional to their contributions.

As slow and cumbersome as public discussions can be, they’re almost always preferable in the long run. Making important decisions in private is like spraying contributor repellent on your project. No serious volunteer would stick around for long in an environment where a secret council makes all the big decisions.

Also, first impressions count. The project web site should make it clear what the project is about and what the status of the project is. Downloading a project snapshot and getting started should not require a lot of fiddling around.

How to get people to work together?

One of the best ways to foster a productive development community is to get people looking at each others’ code.

What infrastructure is required?

The minimum infrastructure almost any project will need is:

• a web site
• archived and searchable mailing lists
• a version control system containing everything except generated files
• a bug tracking system
• some kind of real-time chat

If you also have a Wiki take care of duplicate content and inconsistent style:

have editorial standards, and demonstrate them not only by posting them, but by editing pages to adhere to them.

This is important because:

wikis will amplify any failings in their original material.

Proper discussions should take place on mailing lists, not in the bug tracker.

Who makes the decisions?

Most projects either have a “benevolent dictator” or a some kind of decentralized decision making process. “Benevolent”, because:

quality developers won’t stay around unless they have some influence on the project’s direction

Forks, are the reason there are no true dictators in free software projects.

The “benevolent dictator” is often the founder of the project:

if it’s simply obvious to everyone who should be the [benevolent dictator], then that’s the way to go. But if no candidate for [benevolent dictator] is immediately obvious, then the project should probably use a decentralized decision-making process

The [benevolent dictator] position is neither acquired nor held by virtue of intimidating coding skills. What is important is experience and overall design sense — not necessarily the ability to produce good design on demand, but the ability to recognize good design, whatever its source.

As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems.

How does this work?

Most conversation in a project is on technical topics [...] Consensus-based governance works well because it blends seamlessly with the technical discussion itself. By the end of a discussion, there is often general agreement on what course to take.

Consensus has its limits, though:

Consensus merely means an agreement that everyone is willing to live with.

When Consensus Cannot Be Reached, Vote

But voting should be rare:

Don’t think of voting as a great way to resolve debates. It isn’t. It ends discussion, and thereby ends creative thinking about the problem. As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes. This happens surprisingly often

Better decisions can be made by using “approval voting”, where each participant can vote for several proposals.

Who gets to vote? Use an existing distinction, e.g. everyone with commit rights.

How to participate as a company?

First of all, “play by the same rules as everyone else”.

“credibility is a valuable currency to have in technical discussions: it’s immunization against having one’s motives questioned later. In the heat of argument, people will sometimes look for non-technical ways to win the battle.”

What about communication skills?

The ability to write clearly is perhaps the most important skill one can have in an open source environment.

Some tips:

Write in complete sentences, capitalizing the first word of each sentence, and use paragraph breaks where needed.

In IRC or similarly ephemeral forums, it’s generally okay to leave out capitalization, use compressed forms of common expressions, etc.

Always take care to choose a good subject line in e-mail messages.

Observation on the communication style of the typical open source project participant:

No greeting, no sign-off other than his name, and the message itself is just a series of questions phrased as compactly as possible. [...] A degree of terseness that would be unacceptable in normal social interactions is simply the default for free software hackers.

Nevertheless you should consider that

by being sensitive to the tone of your own writing, you can have a surprising amount of influence over how others feel, to the ultimate benefit of the project.

How to keep discussions on topic?

It is unfortunately very easy, and all too typical, for constructive discussions to lapse into destructive flame wars.

Bad behavior should be “consistently called out” but:

never make the meta-discussion the main topic. It should always be an aside, a brief preface to the main portion of your response. Point out in passing that “we don’t do things that way around here,” but then move on to the real content, so that you’re giving people something on-topic to respond to.

Regarding “rudeness”:

One of the defining characteristics of open source culture is its distinctive notions of what does and does not constitute rudeness. While the conventions described below are not unique to free software development, nor even to software in general — they would be familiar to anyone working in mathematics, the hard sciences, or engineering disciplines.

Technical criticism, even when direct and unpadded, is not rude. Indeed, it can be a form of flattery: the critic is saying, by implication, that the target is worth taking seriously, and is worth spending some time on.” Also: Blunt, unadorned questions, are not rude either. Questions that in other contexts might seem cold, rhetorical, or even mocking, are often intended seriously, and have no hidden agenda other than eliciting information as quickly as possible.

How to deal with truly rude people:

comment on the rudeness the first time, and from then on, either ignore them or treat them the same as anyone else. If they continue being rude, they will usually make themselves so unpopular as to have no influence on others in the project, so they are a self-containing problem.

Discussions are unproductive when they are not concrete enough:

consensus is hardest to achieve in technical questions that are simple to understand and easy to have an opinion about [...] People can participate in those arguments forever, because there are no qualifications necessary for doing so and no clear ways to decide (even afterward) if a decision was right or wrong

There are also a few “holy war” topics on which it is unlikely that agreement can ever be reached. Simply saying “Can we please just drop it?” will not help. Consider giving up unless you really care, but remember that “giving up is effective only when done gracefully” (i.e. don’t say things like “I never though this was a good idea anyway”). If you feel that giving in would delay the project too much, justify your choice as “practical”, rather than as the “academic best”.

Once in a while there are “difficult people”, i.e. people “who are not overtly rude, but who manipulate or abuse the project’s processes in a way that ends up costing other people time and energy, yet do not bring any benefit to the project.” Before you attempt to kick anyone out of a project, be sure to gather evidence and get support from other participants, or your actions will backfire.

How to handle growth?

The more a project grows, the more important this sort of consistency becomes. Consistency means that everywhere people look, they see the same patterns being followed, so they know to follow those patterns themselves. This, in turn, reduces the number of questions they need to ask. The burden of having a million readers is no greater than that of having one; scalability problems start to arise only when a certain percentage of those readers ask questions. As a project grows, therefore, it must reduce that percentage by increasing the density and accessibility of information, so that any given person is more likely to find what she needs without having to ask.

How to deal with versioning?

Those three labels — Alpha, Beta, and RC — are pretty widely known now, and I don’t recommend using any of the others, even though the others might at first glance seem like better choices [...] But people who install software from releases are already familiar with the big three, and there’s no reason to do things gratuitously differently from the way everyone else does them.

Starting from the 1.0 release it makes sense to distinguish:

• major releases: new features, may be backwards-incompatible
• minor releases: some new features
• micro releases: bug fixes, small improvements

If you don’t want to halt all development while a release is being prepared you will need to branch.

How to deal with politics?

The distaste for politics is especially strong in engineers because engineers are bought into the idea that some solutions are objectively superior to others. Thus, when someone acts in a way that seems motivated by outside considerations — say, the maintenance of his own position of influence, the lessening of someone else’s influence, outright horse-trading, or avoiding hurting someone’s feelings — other participants in the project may get annoyed.

But “no one is above politics” because “politics is simply what happens when people disagree, and successful projects are those that evolve political mechanisms for managing disagreement constructively.”

If you delegate a task, always follow up!

If someone does not improve in response to criticism, the solution is not more or stronger criticism. The solution is for the group to remove that person from the position of incompetence, in a way that minimizes hurt feelings as much as possible

Watch out for participants who try to stake out exclusive ownership of certain areas of the project, and who seem to want to do all the work in those areas, to the extent of aggressively taking over work that others start. Such behavior may even seem healthy at first. After all, on the surface it looks like the person is taking on more responsibility, and showing increased activity within a given area. But in the long run, it is destructive.

Finally, remember to credit people, but always be specific.

What is a “dashboard”?

A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.

The author identifies a wide range of uses for dashboards ranging from sales to server monitoring. Both Confluence and Jira have simple dashboards. Dashboards could also be useful for keeping track of web server or annotation statistics.

There is a lot of advice on design issues beyond dashboards:

Customers are expert in knowing what they need to accomplish, but not in knowing how software ought to be designed to support their needs. Allowing customers to design software through feature requests is the worst form of disaster by committee.

Three kinds of dashboards are distinguished:

• strategic (read only summaries)
• analytical (drill down summaries)
• operation (real-time alerts)

One of the main tasks all dashboards must support are comparisons across time or related categories.

There are quite a few dashboard products in the market. The author doesn’t seem to be enthusiastic about any of them and uses plenty of screenshots to illustrate his points.

Another common problem on the dashboards that I find on vendor web sites is the abundance of useless decoration. They either hope that we will be drawn in by the artistry or assume that the decorative flourishes are necessary to entertain us. I assure you, however, that even people who enjoy the decoration upon first sight will grow weary of it in a few days. [...] Blank space is better than meaningless decoration.

Other pitfalls include:

• data doesn’t fit on a single screen
• not enough context information is given to help determine if data is problematic or not
• excessive detail which slows down comprehension (decimal digits etc)
• important data is not highlighted

There is a chapter on the basics of visual perception because:

You don’t need to be a graphic artist to design an attractive dashboard, but you do need to understand a few basic principles about visual perception.

For example, one should use soft colors unless one wants to focus attention on something. Colors should variate in intensity rather than hue to ensure that people who have problems with color vision can make the distinctions, too. Characteristics such as size or shape are suitable for representing either qualitative or quantitative data to different degrees.

To clean up a dashboard the author recommends going through the following steps:

1. Reduce the amount of “non-data” pixels. This includes 3D effects, unnecessary grid lines in graphs, borders, background decorations and color gradients.
2. De-emphasize remaining “non-data” pixels. Reduce thickness, tone down color etc.

Another issue are navigation items:

place [navigation items] in an out-of-the-way location such as the bottom-right corner of the screen and mute them visually, so they won’t compete with the data for attention

Instructions should be made available through pop-ups rather than be displayed directly. This is what we do in the niceprot view. Also, general help is not accessed during normal use and should therefore be reduced to a single help link.

The author is critical of many frequently used chart types such as gauges (waste of space), pie charts (difficult to make quantitative comparisons) and 3D graphs (for non-3D data).

Regarding bar and line graphs:

• Don’t use line graphs to display data along a nominal (e.g. category) or ordinal (e.g. rank) scale, only for intervals (e.g. time), unless grouped (e.g. by month).
• Use stacked bar graphs only when the emphasis is on the sum, not to visualize the differences within.

Icons can also be useful, but all you usually need are:

• alert
• up/down
• on/off

Meaningful comparisons should be encouraged and meaningless comparisons discouraged through spatial separation and colors.

The book ends with several case studies, showing both good and bad solutions.