Light Refinements

If you missed it, the new screenshots were released from Ubuntu's new light theme. It was announced over at Canonical's design website. Having a design website was a very important and significant addition, and I applaud whoever pushed (likely hard) to have a dedicated site.

Before anyone reads any further, let it be known that doing this sort of interface design is dasterdly difficult and complex work. It is nightmarish to execute, massive in scope, and tricky to make technologically sound. And that is before we even begin to discuss aesthetics.

Creating interfaces is the stuff of nasty nightmares and it should not for a brief moment be considered trivial to achieve. Have a wander over to GNOME-look or KDE-look if you need further evidence.

What is in It?

There are some much needed changes to the theme. Hard to guess exactly how much was due to a lack of having a GTK coder in the house. They have since hired the GTK developer of Murrine.

The above is a shot of the work in context.

We can only assume the wallpaper will change. Hopefully it will change dramatically. It is by far the most disturbingly poorly crafted, ill-inspired, and outright awful creation of this mise-en-scene. As I and a few others have already mentioned a while ago:

1. It lacks pathos. Without a clearly defined audience, this is impossible.
2. It lacks craftsmanship. The presentation has the appearance of a hobby GNOME-look hackjob.
3. It lacks concept. We finally have some conceptual guidance with "Light". We end up with what happens when someone drinks too much brandy after their salmon souffle.

Downright shoddy. And why is it important? The default theme, even with these much needed improvements, drags down the whole presentation into the GNOME pile of steaming mediocrity of yesteryear.

Overall Opinion

It is a huge improvement over the last iteration. There are a number of reasons for this that I'll try to explain below. There are likely still more than a few forks in the design path worth exploring, but strictly in terms of visual representation of user interface elements, it is a large and significant step forward.

Active Selections

This is likely one of the points that really feels a little too much. It's orange. And it's everywhere.

I can imagine there are plenty of Libre types that are shouting out about the inevitable consistency facet. Consistency is a means to an end. There are other techniques.

Have other paths been explored? Saturations? There is something about it that feels like the glaring blue or red lights that equipment makers inadvertently put into their devices only to find out that it lights up someone's entire room in the dim lighting.

It is worth focusing on a few elements:

The blatant disregard for craftsmanship on this selection box unfortunately pulls down a good deal of the work. It is too bad they didn't leave this hidden in the screenshot.

It's square. Yep. And that's the list of compelling features.

What I would have hoped for was some sort of underlying schema for the highlights. Are they slightly 3D? Are there lighting guides to follow? Is there something else to this presentation that lends toward a centralized style?

Here is another example:

This menu selection item shows a much higher degree of craftsmanship. There is more going on there. Unfortunately, it still seems stuck in the Tango-outline-outline-inset-outline style guide that unfortunately drags it down. Again too, the tone seems pretty heavily saturated. I note this because of one of the more impressive decisions they made coming up next.

Monochromatic Interface

Thank goodness. It finally happened.

It is not beyond the realm of reason that some talented designer will make a lovely example of hue based interfaces. I don't believe I have seen one yet in Libre software. Further still, lumping hue into the default background of interface elements likely coaxes the little hobgoblin out of his nest.

When you add a subtle colour hue to an interface, you end up inadvertently painting the whole desktop in a wash of colour. This takes us back to the brown, brown, and a little more brown era. Too much. It would be like painting your living room walls the same colour as your couch and then buying a matching carpet.

It is the exact same erroneous mistake legions of people make when they walk into their home hardware depot and make a paint selection based off of a five centimetre swatch.

Removing all of the hue is a solid step forward. I can only wonder if they avoided doing it in the last incarnation to avoid the more blatant connections to the mainstream operating system that has similar cues.

Yes it on one hand could be more cargo cultish. Yes it is running away from an attempt to create a successful slightly hued interface. Yes, it is.

As a design decision though, it elevates the work from its previous incarnation merely by avoiding a poor execution.

Scrollbars and Troughs

On the whole, these are vastly better. Why?

I'd make a case that they don't look as lazy as they did before. Prior to this, we had a linear gradient tossed into the background. Now we see some craftsmanship. A little bevel near the edge and some attention to lighting in the progress bar trough. With the progress bar pill we see more care and attention to the details in the pill.

Again though, I have to wonder about the outline on the orange pill. It seems like an overly simplistic method to gain contrast, doubly so when considering the relative value of the hue and saturation of the pill. It is a minor note, but one that I'd like to see explored further with alternate manifestations.

Still, leagues better than the previous incarnation.

The scrollbars haven't changed dramatically. The troughs show a little adjustment.

We can see a little outlining on the scrollbar arrows now where they were part of the background prior. The trough has a less contrast gradient inside it, which likely helps to pull away from the feeling of a lazy linear gradient.

Again, the outline technique seems somewhat too easy a design path. There is likely a better way to create form without relying on the simplest technique. Remember how children learn to draw. They start with outlines.

The three line gripper does, unfortunately, seem to echo the design path of yet-another-operating-system, and as such, I'd strongly try to avoid it. 

What would happen with further exploration of the scroll bars? Is there a unique approach out there that avoids the triple lines of the gripper and the outline method of defining its form?

For the reasons cited, I'd label the progress bar adjustments much improved. The scroll bars less so, but still avoiding the earmark laziness of the previous version.

Typeface

The new Ubuntu typeface is in place and it has a serious push on the overall feel.

The impact the type has on the overall system cannot be understated. It is diminutive in nature and strips away the bold and clunky looks of yesteryear for a sense of sophistication.

There is a current obsession with gutters and padding in GNOME. I hope that some astute individual steps up and voices a concern. Egregious gutters, padding, and whitespace create interfaces that end up feeling massive and heavy.

There is no difference between the blight of horribly cramped interfaces and those that suffer from airhead syndrome. Evaluate the balance in context. Executed with a poor obsession in the name of consistency will result in an identical feeling of heavy and ropey interfaces. Perhaps that is something the people pursuing those paths will need to learn for themselves.

If there were one gripe I'd have with the typography, it is our ridiculous insistence on using bold letterforms in the title bar. We finally managed to get the text left aligned, now we just need to ditch that heavy misuse of bold.

Window Decoration

Neither here nor there as a design choice.

The buttons do show elevated craftsmanship and is always a good thing. There is much to be said for showing detail in one's work.

I fear we lost the trench a little with this incarnation, but again, it feels neither here nor there. Do we need the trench at all? In terms of lighting, it seems like a slight oversight that the lower lip isn't catching any light.

The issue, combined with the bold text as cited above, is that the window header still feels heavy. Perhaps this is a combined result with the new typography lightening up the overall appearance. The massive height of the window border just seems ridiculously overweight. 

Could we trim the fat by de-bolding the type? Could we shave some pixels off?

For all of the people out there willing to shout out that empty word 'usability', I'd throw back 'design problem' and suggest we solve it.

If we can't hit an aesthetic target and move our windows around, we have utterly failed. Is the window title bar the only solution? Are there others? Can we address the ability to grab a window and maintain a strict aesthetic voice?

I'd hope so.

Buttons

Outline. Inset. Infill.

Heavy as a lump of lead, these things are visually glaring, although not quite as much as their predecessors. These are lacking the craftsmanship we should strive for, and instead replace that with that patented goofball Libre outline, inset, outline, outline, inset routine. In addition to being derivative of every other interface theme out there in Libreland, they create an awkward sense of elevation.

The internal tone, being darker, sets them out from the background quite significantly. This would head in the opposite direction of the instrumentation panel feel of the progress bar troughs.

This is certainly not the kind of thing you would find on the front face of audiophile, videophile, or high quality equipment. This is the kind of button you would find on the front of a Goldstar or one of those All-In-One remote controls.

Poor.

Sliders

I am a little torn on this one. While it exhibits the same improvements as the progress bar troughs, it simply piddles its gains away by including that cruft of Tango inspired blemish upon it. Hideous. Huge.

What would more greatly suit the trough in this instance? Were materials considered? What might fit this overarching thematic?

These details are the kinds of things that make presentations spring to life. It fills them with emotion. It gives them style and nuance. Think about a kitchen and all of the elements in it. Everything matters. The materials that the countertops are crafted out of and their ability to coordinate with the cabinetry. 

These elements are like the door handles and cabinetry clasps. We should pay greater attention to them and imbue them with style. Are they hematite? Is there a unique stylistic choice here that we could visually echo elsewhere like spice in a food dish?

Checks and Radios

This one still obviously appears to need exploration.

These are neither here nor there again. Instead, they should likely be one more detail that lends to an overall styling.

It isn't there[1].

A Closing Riddle for You

If one takes anything away from this it should be to note that there are some serious improvements in this iteration.

While one could certainly ask questions about the saturation of the orange selected elements and other design questions, the whole mise-en-scene cannot be seen as anything other than progress. This is not without the hobgoblin of yesterday still upon us.

We need to ask some tough questions in Libre software. As with most of our interfaces, is this a high end instrumentation panel or a Play-Doh (no pun intended) inspired iteration on the standard trend? We should address the question with a clear answers, and not accidentally or intentionally wrap motifs in from that past era. It may require radical rethinking and a conscious avoidance of the old ways.

I say bring it on. I beg thee.

I have one final point, but it is a subject of large gravity, and as such, the foundation of another post. I'd ask you all to leverage your thinking upon it.

When we view these things, we see them as static two dimensional images like looking at photographs from our past. 

Just as with the photographs, this is not how we experience them. This is not how we live them. The tools used to develop this interface are trapped in that world. As I have said before, the tools inform the design as the chisel informs the wood. 

What is missing? It is so obvious it can go unnoticed.

It should shape our design decisions. It should be mandatory to elucidate our visions within it. It opens up vast regions of interface interaction paradigms that have yet to be tapped.

Let's see if you have the time to figure it out. ;) Post a comment if you do. If you can, please post the comments over at Librescope. 

Thank you all for reading...

[1] I suppose one could make the argument that in fact there is no stated overall styling. Not really necessary for someone working alone in a dark room, but certainly helps to evaluate whether or not it is successful in that effort. What is it? I'd love to hear it.

Friend, You are a Naive Young Fellow Shouting for Attention

There is no shortage of various blog postings tackling the "Problems with Free Software(TM)." Myself? Guilty as charged.

I can't change the fact that my paintings don't sell. But the time will come when people will recognize that they are worth more than the value of the paints used in the picture. - Vincent van Gogh

I stopped to focus on this recently with another posting, attempting to explore the perils of absolutism. The world where everything has a clearly defined description and is easily accessible. It appears easy for us as a culture to rally behind enticing words. "Beautiful", "Elegant", "Success", and "Better" are a few such terms.

The Problem with the "Problem"

It certainly has the earmarks of the above terms doesn't it? It is an easy word to rally around and get people to arrive at a democratic consensus. We have a "Problem." Agree?

When we come down to defining the term, it gets much more murky. It is, I believe, a question of framing.

There are apparently more than a few individuals that are willing to run around screaming "Let's fix the house's problem!," garnering a good deal of support, and then perform act three of the Three Stooges as they bumble around and bump into each other not really knowing what problem they are addressing.

In some instances it is worse. Sometimes, they bumble around pointing at vague nothingness or the hobgoblins of a bygone era.

Mythical Problem #1: Zealotry or Core Value?

While it is easy to cite RMS as the clichéd and vocal Free Software supporter, I'd hope that many would accept he is an exception. His eccentricity and unique perspective gave birth to the notion of Free Software in his head. His steadfast determination and unflinching vision may have had a role in a significant portion of the Libre software available today.

If we sat back and did a count of people like RMS, I'd dare say the number is precisely one. What is really the "Problem" here then?

Vocal Free Software supporters? I need to wonder...

Mythical Problem #2: Significant Market Share?

One of the "Problems" often cited is the need for a dominant market share. Microsoft has enjoyed that for a while now. If you had to choose, would you rather be Apple or Microsoft right now?

I'd ask you to give serious thought on that front.

Does BMW have significant market share?
Does the University of Oxford have a significant market share?
Does Apple have significant market share?

Are those companies and their associated cultures valued?

Design for Whom?

Success, in these instances, seems to hint more at mind share than market share. When you are of AudienceX, where do you choose to invest your mind share to fulfill your needs?

Would exchanging core values of the above companies in exchange for market share be more appealing to AudienceX or less?

If we can accept that a company culture can be valuable in its uniqueness, it is possible to define successful mind and market shares around that uniqueness.

In the end, I'd ask you to consider the who again. I'd echo a question I made in an earlier post - who do you want to be a member of this culture?

Do you want the Cory Doctorows and Lawrence Lessigs? What are their writing needs? How do they desire the tools to behave? Design to those needs.

Do you want the Richard Feynmans and Madame Curies? What are their particular needs? What workflows and systems would be more appealing to them? Design to that.

Do you want the Ada Lovelaces and Richard Stallmans? We luckily already have a few...

What about all of those nameless people in oppressive countries that run the very real risk of being executed in the name of their radically progressive thoughts? While it was a dark moment of our history, it also is happening all around us right now. With mainstream systems and devices now succumbing to government and implied market pressures, can Free Software be designed to meet their needs? A distribution that is a cornerstone of communicating out of those places? Encrypted messaging, publishing, data storage, and remote secure servers?

Do you want random voices that would prefer nothing more than already existing alternatives such as Apple's OSX or Microsoft's Windows?

We.

It is a powerful word.

Who are we? What do we wish to become?

Strictly subjectively, I believe those are critical and foundational problems we need to now address. Those are the design issues at hand.

Define it. Frame it.

Achieve it.

Culture's worth huge, huge risks. Without culture we're all totalitarian beasts. - Norman Mailer

Abhorrent Absolutism

Mark Shuttleworth is prone to saying some extremely astute things.

In this instance, it was Mr. Shuttleworth's opinion on the culture of Free Software and its ability to solve problems. Not exactly a shocker for many of us. It's an easy buy-in.

What was astute with his suggestion though, was a perception of why things failed. He suggested that a problem is met with failure when it is improperly framed.

The Thought Applied to Art and Design

If we accept that many bright minds are adept at solving problems, why then, almost unanimously across the board, does our outward manifestations of art, design, and pathos so shamefully fail?[1]

Is it possible that we aren't framing the issues properly?

Those Darn Words

It's deadly simple to throw out words like 'elegant', 'success', 'quality', and 'beautiful'. We do it all the time in the Free Software culture.

Those are easy words aren't they? "We should be beautiful not ugly!" How difficult is it for us to rally around that statement? Pretty simple isn't it?

And then the masses wander off and start creating 'elegant', 'beautiful', and 'quality' things.

And of course, we are 'successful'.

Never mistake motion for action. - Ernest Hemingway

Yikes. I'm Scared

If someone suggests for a brief moment that we are fundamentally incapable of discussing things using words like the above examples, they would likely be derided as one of those time-sucking goblins. The energy wasters. Those haters, they will always hate.

If you ask an individual to define a single term such as 'elegant', a random smattering of opinion would likely come forth. Ask two individuals, and now we have some difference of opinion. Discuss things long enough and suddenly the topic drifts from defining a word to a dismal path of semantics where the horrible vertigo of solipsism sets in.

Aggh! Avoid the issue altogether. We all know what they mean, move on. That's how we get things done right?

A Process to Negotiate the Difficult Terrain?

If you look to the rampant diversion of opinion on the new Ubuntu Unity Audio indicator over at Mr. Shuttleworth's blog, you can quickly see that something is wrong here. How can one party quite rightly suggest that we should not include album art and another, equally rightly, suggest we include it and make it bigger?

What is going on here?

I believe, at the core, our inability to tackle the massive ball of presence, emotion, and aesthetics is fundamentally moored in our inability to, as Mr. Shuttleworth has said, frame the problem. This isn't about wasting time trying to define nebulous words. This isn't about time sucking a project into the pooper.

At this core, if we can find a process to negotiate the complex terrain, we may be able to leverage the amazing power of Libre software development against the traditional roles of art, design, aesthetics, and emotion.

The following suggestions are built up on quite a few years of watching Libre culture beat around the proverbial shrubbery of the issues at hand:

1. Accept that absolutism does not exist. In doing so, we accept that we must frame our design problems far more accurately than a small team working alone and isolated in a specific culture. Even our concepts of time, quality, and global culture are tainted by our own subjectivity. Accept this. Embrace it.
2. Define who you are designing for. What are you attempting to address? How? Why? Are there specific needs that this audience requires? In doing so, we frame our evaluations and make them manageable.
3. Extend and colour design goals with tangible analogous examples. What sort of emotion is intended? Are there several visual examples that flesh out a term? Create a mood board or similar presentation at the beginning of a project. In doing so, we help to frame the overall look and feel to the various participants.
4. During design, evaluate against the who. By framing the audience in (2) above, we allow our estimations to be educated and informed. While it will not ensure success it will assure a chance of success. When faced with opposing opinions on potential design paths, always evaluate the paths in the light of the who.
5. Success and failure should be evaluated against the who, not the individuals involved or parties outside of the audience of the intended design.

A point of view can be a dangerous luxury when substituted for insight and understanding. - Marshall Mcluhan

Absolutes are Absolutely Ludicrous

There are many successful projects in the past that have likely never had to tackle the notion of absolutism. They just hammered out their ideas and carried on.

Those projects however, have one fundamental difference to Libre culture though - they never sought to collaborate and interact on a global level[2]. They didn't have to validate and itemize design paths in a vast and disparate group of people. They didn't have to negotiate a difference of cultural perspective to thwart wasted energy and bikeshedding.

For those in Libre culture, absolutism fundamentally cripples our ability to frame our design issues correctly.

We are marching into new territory.

Here's to applying new approaches...

[1] This is obviously a gross oversimplification. I don't believe the core of the statement to be false however. Exceptions to the statement obviously exist in the form of Firefox and Chrome, but by and large, my interests aren't with promoting the success of those projects but rather the unfortunate state of affairs for the more important bigger picture.
[2] There are some fascinating stories of massive international corporations facing the identical issues. You could likely Google for Wal-Mart and Glocalization. That however, is the subject of another post.

Ubuntu's Audio Panel - Who's Fooling Whom?

It's All New Design This Time! No Really!

This is a good exercise that touches on why building a culture is so important. Every time I look at the new Ubuntu music-applet-sound-all-in-one-super panel I struggle against my instinctive reaction.

I see a long standing history of art, design, presence, aesthetics, and emotional experience being neglected. It chases us like a dark spectre of our past.

This isn't new. These are the same old patterns repeated while professing to be different.

The lady doth protest too much.

What the Hell Has Gone Wrong?

I ask you to look at the following samples. Even a passing glance at this should prick the hairs up on your arms with the same morbid reaction to looking at a decaying corpse.

There is nothing to love here. Nothing. And yet our community cheerleaders seem absolutely blind to the inherent kludgey issues.

It is, for all intents and purposes, hideous. And better still, it is hideous wrapped up with some absolutely questionable design.

Chic. Right?

First, we roll out an implementation. Then we retroactively fix it. Right? So the original implementation for the sound panel thingamajig rolls out, and what do you know, there's an issue. To quote Mark Shuttleworth:

Note the tight space for the track data, and hence the ellipsis.

And the result?

Now somewhere, someone might be going "That's hip right? Overlapping text on an image is pretty stylish right?"

It sure can be. Is this it? Unequivocally not. It's a solution to a self made problem.

Let's ask ourselves exactly what this applet is supposed to be doing? I'll guess at:

1. Provide a central interface that allows us to control all of the audio.
2. Provide a region that shows related audio elements. In this case, it is the output of the music player.

I would ask you though, is this about the application or the data it represents? Why? Because in this case, I would make a strong argument that the audience could care less about the application level. In fact, what is important here, and likely why we are including it in a menu, is the music.

What music is it? Is it playing? Can I skip a track? Can I replay a track?

Does the target audience care what the music application is?

In the above 'design', the data has taken a second-rate-low-end-back-seat. We jam ellipsis in that effectively destroy a meaningful representation of the data. If we subscribe to the idea that the data itself is what is important, we have completely destroyed the entire purpose of this design element.

Secondly, if the data is indeed the purpose here, why is the album art given the same back-seat-third-rate-representation? What might be more effective?

I'll try to touch on why I believe these sorts of decisions get made later, because I do believe there is an underlying rationale to the unfortunate choices.

Visual Flow

Graphic layouts will pull eyes along a path. This is a complex series of interactions between colour, value, dimension, and other such areas wrapped up in the audience's experience. With this panel applet, I'd make a strong case that there is a lack of visual flow.

Why?

There are many minor details in this presentation that I would suggest destroy the visual flow and leave a general sense of hodge podge.

1. Inconsistent padding and gutter room. Of note would be the strange padding between the two sound icons on the main volume control and the distinct lack thereof on the timestamps on the progress meter.
2. Visual flow. The weight of the buttons comes to mind. It is one thing to draw attention to something using dimension, but another entirely when the element in question is nothing short of an acrylic Elvis painting on black velvet.
3. Much information. If the intentions were to be a quick panel, the information provided suggests otherwise. If we were to try and figure out why we would need these sorts of things in a quick-to-access menu, we might make some gain. How often is the target audience requiring to choose a playlist? How often is the audience needing to make adjustments to the sound preferences? Are the features presented useful when analyzed in conjunction with the audience that is using it? 

Some wide open questions that would need further thinking and, more importantly, perhaps some research.

Broken Semantics

This one seems glaring. At the top we have two elements that appear to control system level audio. Then, again, way down at the bottom, we have a preferences menu item.

If we use proximity, should we deduce that the sound preferences are a part of the music playing application?

Stuff-it-in-a-Text-Menu(TM)

This trait has been appearing with ever more frequency. It drives me to distraction.

Putting something in a menu is not design. It is lazy.

I'll predicate this with a hypothesis: The tools inform the design as the chisel informs the wood it carves.

If all of the work you do is trapped in a prototyping sketcher, Flash, or Inkscape, or GIMP, what is the inevitable byproduct of that? How do predefined notions of user interface libraries shape a perception of design interfaces? Should they? When all you have is a hammer, everything tends to gets treated like a nail.

Much like the above ellipses 'solution', it is mired in the tools used to arrive at a solution. GIMP is strictly two dimensional. If we start hacking away in GIMP before we have arrived at a vision, our solutions will inevitably be informed by the tool in which we are hacking it out.

At no point did someone stop and develop a vision / solution first and then develop in the direction of that solution. No, instead, the path of least resistance was presented. Solve a problem that we actually created.

Had the starting point been a vision, multiple viable solutions may have presented themselves. Could we animate it? Could we elevate the experience in doing so? What other contemporary examples harness representational data in a way that is unique? Is there anything to be learnt from them?

Many possible paths, and yet we are stuck with the data destroying ellipses.

So how do we present options now?

In addition to being a lazy solution, in this context, one could make a pretty good case that the menus and resultant text heavy presentation are pulling away from the visual flow. There is much to read and, as a result, much visual noise. Indeed, the top most "Mute All" isn't even a menu. Is it a button? Why isn't it a button? What cognitive dissonance is created as we present our audience with entirely different interaction semantics? "Choose Playlist" also has the added triangle that somewhat disturbs the right gutter.

What might a viable solution have been that didn't require a menu? We certainly could have used some sort of iconic button to reduce the visual noise and elevate the flow, but should we stop there? Are there other innovative solutions to be had that we aren't seeing?

The Best Biggest for Last

It is far to easy to simply cringe at those buttons and walk away. But why do some cringe? What is wrong there?

Let me roll through a subjective romp of neural firing:

1. A new styling. There are drop shadow cues on the interface glyphs. This appears new. I was unable to find another sample of this technique anywhere in the system. Currently, with no other examples anywhere in the system, this is an issue as it draws significant attention to itself in terms of the visual flow.
2. Base form does not reflect interaction frequency. There is an awkwardness of the base button forms. The forward and back seem to be getting too much visual say as though their importance is, strictly in terms of visual gravity, as important as actually playing or stopping the music. Compare against the Firefox interface explorations which each have a much more stable set of visual gravity that parallels their frequency. They also exhibit much more craftsmanship than the above buttons.
   
   
   
   
   
   
3. Bevel styling. Tied to (1) above, we have to ask ourselves a question. I am entirely for making changes and adjustments if they have been thought through. This doesn't appear so. If this is indeed a new anchor for a new aesthetic style, should we should be pursing it?  Has there been a visual series of studies or explorations to back up an entirely new aesthetic direction using this as an anchor? Should there have been? How would this element handcuff future elements in terms of design direction and presence?

Not Convinced

All in all, I'm not convinced that we have any more design thinking here than we did four years ago. Personally, this looks like the same patterns repeated.

I am not criticizing Canonical's desire to forge ahead with their plans. In fact, I'd be of the opposite belief. I strongly encourage more Libre companies to push ahead with dramatic and radical changes. We need that sort of stubborn resilience. Unfortunately, in this case, I believe it is seated in some questionable aesthetic, design, and interactive issues.

As a complete outsider, I can see this effort as an extension of the heroic hacking that has taken the Libre movement so far. "Shut up and code!" Indeed, if it weren't for that attitude there would be nothing here to discuss, and for that reason alone it should be applauded.

However, when it comes to raising the bar for interaction paradigms and interfaces, I have to question the validity of not stopping at intermittent design checkpoints and re-evaluating the plan. At which point does the hacker creed of code first create a series of problems that now require hackish solutions, such as the ellipses issue? At which point do we stop and ask ourselves just what the hell we are trying to accomplish?

Was there any thought given to what will dictate whether this has been a success or failure? What are they?

Art, design, presence, aesthetics, experience, and emotion are nebulous creatures. They cannot be tackled with the same tools that has brought our rich culture to where it currently rests. The patterns that may have yielded success cannot be assumed to provide success in other areas. The same logic may not apply. The process may need to be different.

It appears to be the same hacker ethos, the same hacker sensibilities, the same hacker solution process, all over again but now applied to art and design.

It looks like history repeating itself.

A tremendous thank you to all of the people that have spoken up, sent email, instant messaged, and otherwise to voice your caring. We need more people like you to engage the culture. Please do.

A Postscript

Mr. Shuttleworth left a comment here that I believe deserves some attention in the main body of this article. As much as it is easy for idiot monkeys like myself to throw out yet-another-worthless-and-empty opinion, he is the one that has invested a ridiculous amount of his own money into Ubuntu. Without him, all of this discourse is moot.

On key values of the panel indicator:

"provide a home for all the apps influencing "what I'm hearing" with suitable metadata and interaction opportunities"

At some point this will likely need to be regulated, no? What applications? Every single one with an isolated sound control pipe? How massive will that applet get? Should this goal be more restricted in scope? I'd certainly think it should.

"do it stylishly"

And here is a core problem with our current Libre software approach.

What the heck is stylish? Seriously. Please give that some thought. Your economic and ethnographic details are specific to you, and as such, they define the words.

What is worse is that not many see how empty such terms are, and instead, go off rendering or clawing at their own take on 'stylish'. It takes us right to where we are now in Libre design - no focused discourse and a mish-mash of directions.

While it is completely acceptable to work with loose semantics in casual conversations, when we start talking about gettin'-it-done, they fall apart. It is rather like the empty allusions to "elegant" I've been seeing popping up in GNOME circles.

In practical terms, providing a more rounded brief or even mood boards would likely have helped to get more people on the same page, perhaps?

You have specifically called this "classy", and I can't disagree with you. Perhaps to you it is in fact, "classy". This is a difference in fundamental perspectives. And in the end, it is really irrelevant what you and I think. This is about an audience. Who is it? They are the barometer, and in the end, we need to speak their language.

"Let's design a panel applet for music control aimed at 20-30 somethings with North American / Western European music magazine sensibilities." and build up around the other design constraints of being a panel applet. Alas, I didn't try to provide a brief on this.

At any rate, you have your own design team there. Start with them perhaps? Surely a productive and creative explosion could happen if the design goal is framed appropriately?

I've kept mocks out of this discussion. I don't believe they are worthwhile. If there is any value at all in this post, it could rapidly be washed away with a subjective response to a mock. Strictly on aesthetics, I'd suggest this one in a heartbeat over what is currently presented. It is certainly in the vein of the clinical presentation, so personally I'd question the validity of such an approach. That said, the execution is far superior to what is currently in place. The other design concerns still stand.

Thanks again for taking the time to drop by...

Libre Computing Neighbor Awareness

Neighbor Awareness as a Guiding Principle

So you install your fresh and new DistroX. Wonderful stuff.

Now you head over to your laptop and install DistroX. Terrific.

And what happens? Until you follow a myriad of installations or manipulations or IP blah blah or password hell, you effectively have two isolated islands.

If we start thinking about needs, we might find a large set of useful implications when analyzing the notion of a neighbor awareness.

Neighbor Awareness?

This isn't attempting to purely replicate any known set of functionality currently out in computing. What I'd like you to dream about is the idea that, via tried and true security options such as OpenSSH[1], every computing device within range, be it IP subnet, Bluetooth, Ad-Hoc wireless, or any other available technologies, becomes a neighbor.

Automagic.
Automatic.
All via a single click.

Let Your Mind Wander

Imagine you log on at your local university. After you log on, you select the neighborhood launcher.

You can see a full listing of nearby computing devices and entities. The presentation isn't a stale listbox, but rather a magical unfolding with full transitions as the entities fade into view. There are a few different filter / group settings that when you hover over the various nearby entities all gracefully sweep into different piles of elements.

You begin typing "A-m-a-n-d..." and as you do so, the public facing avatar of four Amanda's show up in the contextual filter. You find the Amanda you are looking for. You click on here, and a knock-knock-knock sound signals an attempted initiation of connection.

Meanwhile, on the other side of campus, Amanda is working hard on her LLB. Because she lists herself as available, a knock-knock transitions on her living space. She sees you have made a request, and accepts.

From this point forward, full computing interaction can happen. It all started with a single click and built outward. Now you can share files, engage and interact, and other such things simply by interacting with Amanda's avatar. Stretch the imagination and ponder what other needs might be addressed through such a system?

Even more importantly, your securely registered friends and associated devices have automatic detection for the next time around. Turn on your cellular phone, get within range of a contact, or any other registered connection and you are greeted with a notification on all relevant systems.

All of this would be stored via an ask / allow / block system, permitting a full degree of privacy.

Now consider what happens when you attach a cellular phone to your network, or a remote network attached storage device, or another workstation in your basement[2].

Automatic awareness and interactions with a single click.

Some interesting side links that have a similar flavour in some fashion:
DoctorMo explores the idea of contacts as indexed files.
Let's have the computer do the work? Make this mess one click.

[1] Obviously security should be of the highest order. Registered SSH public keys might be a very effective way of permitting or blocking using typical usage scenarios. How to tackle spam attempts is another matter. The point is - we shouldn't get hung up on what we currently have, but rather focus on the end point and build backwards. We have some damn brilliant minds that could likely solve this design issue in a very short period of time. It should also be noted that the technology could easily extend to location based data.
[2] This could likely be extended to a contextual interaction with other devices such as printers. What happens when you drag a PDF to a printer or a FLAC to a media device? Does the PDF print? Does it store it on there? Does a simple radial menu appear with interactions? What about the FLAC? Does it play? Does it transfer / sync it? Much to explore, but at the core we have a very uniform design language here that could likely flower into much more.

Defining Success (and Failure)

A Fictional World of Dartopia

Once upon a time, there was a world called Dartopia.

In Dartopia, they organized their culture around a game of darts. Each participant got a dart and tossed it. Each participant waited until the dart landed and then assigned themselves a score of their choosing.

In a famous match, two of the most esteemed dartspeople were engaged in high battle. Regibauld on one side and Bowlina on the other. It was a heated game.

In the final round, Regibauld made a deft toss that shot directly into Bowlina's eye. He chose to award himself a full five marks on the grounds that the dart hit a target that was close and was therefore subject to Limbaum's Law. Bowlina replied by not even tossing a dart, and cited Hattersack's Law for another full five marks.

The matches in Dartopia all ended in draws. For this reason, Dartopia's spectator numbers were extremely low.

Libre Design - a World of Infinite Success

Much like Dartopia, Libre software suffers a critical and fundamental flaw regarding the pursuit of all things design. When a project has no clearly defined metric for success, it engages in a worthless process of guesswork.

As such, much of Libre software succumbs to a ridiculous debate of bikeshedding or opinionated subjectivity, all the while failing to address whether or not a design aids or fulfills the needs of a particular audience.

What is Success?

Success obviously could mean vastly different things to a near infinite number of people. In fact, any project, from the larger collectives with massive codebases to the tiny projects developed by a single person, could define the benchmark differently. Some might define monetary reward as success while others may define it via vaguer notions of audience satisfaction.

The problem here isn't in the diversity of potential goals for success in Libre software, but rather the complete disregard for defining them in the first place.

Without Goals, All Decisions are Moot

We often see only the manifestations or symptoms of this lack of stated goals. Without the vision, it is nigh on impossible to evaluate whether or not a feature is valuable, needed, or desirable. We have all watched threads deteriorate from legitimate discourse into "Well that's that and we are developing it / footing the bill so please respect this choice."

While I applaud such a concrete decision, we should accept the fact that forging ahead and getting things done / committing code isn't a barometer for success[1]. If we don't define the context of success, how is any success even possible?

Instead of two separate parties wandering like amoebas after two different and nebulous ideas, we would have two powerful sets of minds focused in on solving a design problem.

Who Evaluates Success?

In the end, the core of design is quite simple. Dieter Rams defined a loose set of ten ideas that encompassed his perspective on design. One of them is particularly relevant here:

Good design makes a product useful. -- Dieter Rams

Seems obvious, yes? Why then would a world respected designer feel the need to state it? The demon, as always, is in the details. With a focus on Libre software, the questions are clearer:

Who is the software for? Stating "everyone" amounts to "no one", as Havoc Pennington insightfully said.
What are they trying to do?
What feature helps aid that audience to achieving that need?
What feature interferes or confuses that audience?

In light of those questions, we have a solid entry point for evaluating success. If we examine only the target audience for the design, do they find it useful? Why? Why not? What feature aids that particular audience to fulfilling the particular task / need? What feature is not relevant? How does the design of a feature augment or interfere with the given task / need?

It should be stated with the utmost clarity that, in the end, the success of a given design is determined solely by the target audience[2]. All opinions beyond the scope of the target audience, whether positive accolades or vitriolic anger, are irrelevant.

Certainly it is well beyond the scope of a blog article to figure out how to evaluate the success of these types of questions. Sociology has made it very clear that asking a question in a particular way can often trigger a given response, invalidating the information. Same goes for polls and voting. The need to glean valuable information in a meaningful way is the subject of an entire discipline and separate discussion.

In Summary

While reviewing and assessing information can be difficult and complex, it should not dissuade us from forming clear goals to define our success and failure. We need these goals to evaluate how our designs are working. There is likely much value in forwarding some markers for failure as well. A firm set of checks and balances to guide our design, and perhaps more importantly, evaluate the design choices after they are implemented.

We need less mental horsepower wasted on dissonance and bikeshedding and instead directed toward solving design questions. We need less debating over features and more focus on delivering a need to a given audience in a design that suits them.

Success or failure remains in the eyes of the audience, not the creators. Without defining a set of constraints and evaluating our success against it, we can never hope to achieve it.

Let's allow ourselves to succeed by defining it.

[1] There is an interesting side note here in that we are now in the midst of a flamewar over just such a topic. Should our universal metric for success be purely upstream commits? What if we miss the point and consider this an outbreak of tribalism when, in essence, it is purely a different metric of success at hand?
[2] There can be economic forces at play. It is possible to deliver a successful design that has a net sum loss of funds for a company. That too is a design constraint, but is one that is assumed in the creation of the work as opposed to the evaluation post-creation. It also has less of an impact on Libre software design, although the success or failure of a project in terms of its ability to attract participants, does indeed have an impact on development constraints.

An Historic Moment

Well OK... Perhaps not. :)

This is a testament to gravity. When you first start writing on the web, you are painfully aware that you are but an isolated voice talking to itself. You write. You press publish. And...

Off into the nothingness.

Over time, though, with the tremendous aid of searchbots, minds arrive.

A Loose Thought

A while ago I toyed with the idea that it would be lovely if we had a central area for like minds to gather regarding Libre software art and design. A place free of ZOMGAWESOME cheerleading and HATEHATEHATE of the endless stream of hate sites. A place where the collective feels inertia and strength as opposed to a closed and cliquey corner of sycophantic praise or vitriolic bullying.

In short, a place where people that are passionate about Libre software art, design, presence, and aesthetics can debate, discuss, and engage each other.

Not being a web designer type, I let the thought pass.

Then and Now

As those minds from earlier gathered, some cross pollination occurred. One mind gets introduced into another and gradually a shared set of interests form. A gravity developed. Traction.

Librescope is the product of that gravity.

What is it?

Librescope is the brainchild of Jay over at Kilobitspersecond. He is a passionate and articulate individual with a sharp interest in Libre software design. When he approached me with the idea that there should be a gathering place with coffee shop / art house sensibilities for Libre art and design issues, I was immediately interested. Jay pushed a massive rock up a hill and Librescope was born.

With a firm belief to make publishing content painless, it was agreed upon that it would aggregate our various blogs into one feed with the hope that a community would grow. Out of that, it is hoped that we might find other like minded authors to add to the feed.

A place for Debian, OpenSUSE, Fedora, Ubuntu, KDE, GNOME, XFCE, and every other type of Libre software individual can engage topics that matter regarding art and design. The focus spans all distributions, software, and manifestations. If it is Libre and related to art and design, we want to discuss it. More importantly, we want to discuss it with you.

What it isn't?

Librescope is not a site about cheerleading on distro X. It is not a site where various hate ranters will be given yet-another-forum about issue Y. Comments will be subjectively moderated by our Editor-In-Chief.

In short, it is created for people like you.

Passion

We are hoping that we can grow a passionate community that embraces debate, discussion, and educated discourse. We will do everything we can to ensure that the discussions are pertinent, relevant, and respectful to the members of the new community.

Our current goal is small, and as such, we don't have a formal method of adopting new writers and such. Currently there are two forms of editors: article writers and feed editors. The article writers get their blog posts tagged with librescope syndicated and aggregated to the main site. Feed editors help to tag relevant blog posts and articles already on the web. These too are aggregated on the site. If you have a sustained interest in art and design in Libre software and are interested in contributing, contact Jay over at Kilobitspersecond.

So without further ado, if you or someone you know is interested, please blog, tweet, dent, and link to it. Join us in trying to grow a little Libre coffee shop / art house / design corner of the internet over at...

Librescope.