Friday, March 31, 2006

Factors in Tool Complexity/Simplicity: Vertical- and Horizontal- Features

More sketching...

I think one of the reasons 'simplicity' has become such a mantra is simply that us humans aren't very good at design.

Designing well to support a task requires an accurate model of the task, of the user and so on, and I think we tend to have simplified models.

So if we do the simplest possible thing that works, there's less scope for stuffing things up.

Why aren't we so good at design? I think one reason is the following.

I think our natural tendancy is to provide capabilities or software properties by creating a specific feature(s) specifically for them. These can be called vertical features.

The problem is, because of our simplified models, our attempts to support those specific tasks end up being too simplified, and thus restrictive.

An aspect of this is that the division of labour between the user and the computer is being pushed too much in the direction of the computer. It can be more natural for the user to know what they want to do and to simply find and use the capabilities that are suitable for executing that. If too much is being explicitly handled by the computer, and the user is too railroaded, it no longer remains a simple tasks of the user translating their intentions into operations.

There are also horizontal features, which are not designed for a particular task or property, but provide generalised capabilities than can be used for it. Cut-and-paste is an example. They tend to be lower-level, simpler and more flexible.

Factors in Tool Complexity/Simplicity: Viewing Value as Additive

Some sketching...

Overengineering is one reason why software becomes too complex. What causes overengineering? One reason is having a 'more is better' kind of attitude, seeing value as an additive property, where adding a feature simply increases the system's overall value.

This sort of attitude appears in all sorts of design. In music, people overengineer in this fashion when they try to make something better simply by adding more sounds. In cooking, they do it when they try to add more flavour to the dish by adding more flavours. And so on.

But value isn't a simple additive property, it is a contextual one. You need what impact adding the feature will have on the user's overall experience. What impact does it have on the software's footprint, for example?

As a contextual property, it is a perceptual one. Though we often think of complexity in terms of properties of the software, like the number of features, the organisation of the user-interface, we have to remember that it's not about these things per se, but their impact upon the user's experience. And to evaluate the impact of any one of these, we need to see how it sits in relation to any of the other items that impact upon the user's experience.

Tuesday, March 28, 2006

Late Nights and Early Mornings

On the final night at my last place, when I was moving recently, I staying up all night doing the final packing and cleaning.

I finished around dawn, and since there weren't any trains then, I decided to walk the kilometer or two to my new place.

I tend to be a night-time person, so I don't get to see that time of day that often, but I really like it. The light is warm and soft, and things feel fresh and peaceful.

I also like late at night. Like early morning, it feels more peaceful and more like like I've got everything to myself. Not that I've got anything against the daytime and having other people around, but it's just that those two times feel a bit special.

Understanding Views You Reject

a very good test, i think:

if you consider a view false
you don’t undersand why
it could make sense
to somebody else

then you don’t really understand that view

so is the reason you're rejecting it
only because it doesn’t make sense to you?

Thursday, March 23, 2006

Reasoning Without Assuming The Truth of Your Position

I think this is a very important skill, but sadly a fairly rare one:

Being able to reason about an issue without the implicit assumption that your position on it is true.

Otherwise, you tend to end up with a kind of circular argument in situations where you try to justify your own view or criticise others. You might present independent reasons for these claims, but in actuality, the only reason you think these reasons are true is your implicit assumption that you belief was true in the first place.

The same goes for your evaluation of other's criticism of your view.

What this comes down to is an assumption that your view is correct, and thus an empty reinforcement of that view and a blindness to anything that might contradict it.

Avoiding this requires the following. You need to be step down a level from your specific position, and see the different ways that the situation could be interpreted, and to be able to interpret different views without contamination from beliefs coming from other views. (Of course, you do need to be able to, at the appropriate times, interpret views in light of differing degrees of evidence you have at hand).

This means being able to handle greater abstraction and indirection, greater skills in being able to construct and 'passively view' and then reason about mental structures.

This is a skill they should teach in schools. It would make a big difference if everyone had it.

Wednesday, March 22, 2006

Initial- and Standing- Simplicity/Complexity

There's a distinction that was implicit in my recent post on software simplicity/complexity. It's between the initial complexity the user experiences and the complexity they experience once they have become familiar with the system.

We can call this the distinction between initial- and standing- simplicity/complexity.

The complexity the user expeiences can vary over time. If a feature is well designed then once the user is familiar with it, it may not add much additional complexity. Whereas if a feature is poorly designed, then the amount of complexity it adds can remain over time.

The complexity can vary because it is a subjective thing. It's not simply a property of the item, but has to do with our relation to it.

Monday, March 20, 2006

Us and Them on the Really Large Scale

Just a random thought: discovering life outside the earth might put our instinctive "them and us" conceptualising to good use and help us see all of humanity as more of a singular "us".

Friday, March 17, 2006

Quick Drafting on Tradeoffs Between Local and Global Simplicity/Complexity

I've spoken before (and followed-up here) about the notion of 'simplicity' and how I think people's notion of it is too, well, simplistic, and subjective. (I also gave a link to Linus Torvald's complaint about the mindless drive for simplicity in some software).

This post is about two different perspectives for assessing the simplicity/complexity of software systems, arguing that the one that is typically used is too narrow.

This post is just a very quick draft. It's the kind of thing I'd normally just write then save as a draft in blogger.. but i thought i might as well just post it anyway.

when people talk about simplicity as a desirable property of software
i think their consideration is too focused
on the small scale of a particular application
in that app, they want the core set of features used in the majority of tasks

what they don't consider as much is complexity on the global level
across all of the software they use

i think that greater simplicity at a local level can lead to greater complexity on the global level
what we might be able to do is add a bit of extra complexity at the local level that contributes to a decrease in complexity at the global level
and in fact, once it has been learnt, can lead to greater simplicity within the individual programs

this would be primarily done, I think, by finding the deeper common structure that is present across the different data, tasks and applications present, and providing explicit support for this.

i think this can be illustrated with an example.

consider cut-and-paste.

i seem to remember that, back when i just had DOS on my computer, many of the programs had no cut-and-paste feature. this made them simpler. and if all you could do was cut and paste within that application, it may have been debatable as to whether such a feature would be worth the added complexity.

but cut-and-paste is one of those features that really benefits from being able to use it across multiple applications. you can't fully appreciate its utility unless you consider things on a global scale.

and while cut-and-paste does add a certain level of complexity from the standpoint of an individual program, that complexity is ameliorated across the set of applications, because you only have to learn it once, rather than once-over for each new application.

i think the global level -- the overall experience -- is what really counts, not a blinkered view that only considers individual applications as stand-alone cases.

so what else can be done other than cut-and-paste?

here's an example. much data in systems is sets and lists. we could have an across-system, global capability for manipulating sets and lists. so, for example, set operations such as unions and differences. these would be applicable to any data in the system that is performing unions on them, getting their difference, etc. the specific program could constrain what capabilitys should be applicable to a given set of data.

i often wish I could do such things with MP3 playlists, files in directories, emails and query results in various different apps.

of course, you'd need to figure out a way to handle this in the UI (amongst other practicalities). but that's outside the scope of this post. i'm not talking about specific technical approaches for implementing this, and their feasability in the current system/infrastructure ecosystem, pluses and minus... just trying to introduce the concepts of local and global complexity and the trade-offs between them.

Beatrice Street

To follow-up my last post, I managed to find a new place -- at Beatrice Street in Taringa. It's okay for a last-minute find; the place is quite old, and a little run down, but the room is an okay size, and transport is fairly convenient.

Friday, March 03, 2006

Goodbye to Toowong's Explorer Street

You may have wondered why this blog is called Explorer Street.

Two and a half years ago, before I started the blog, I moved into a unit in Toowong, located in a street with that name, and it's where I've been living ever since. I thought the name had a nice ring to it.

I had hoped to stay here until at least the end of my PhD (probably another two years from now), but the unit is being sold and I have to move out. I really don't want to :(   I don't know yet where I'm going to, I'll have to see...

To Switch-off This Alarm Clock, You Must Solve a Simple Puzzle

"As soon as you can assemble the four puzzle pieces that are popped up into the air at your predesignated time, the thing will finally shut up." Sounds like what I need, though it'd be one of those things I'd hate myself for in the morning :-). US$52. (via Gizmodo)