Thursday, October 15, 2009

Following the Wave

This is in response to a post by geoffeg:

I've just started looking at Google Wave myself. I'm also skeptical but the ideas behind it just may hold some promise.

I agree that email needs to be fixed... more like completely replaced. Maybe google is a big enough entity to make it happen, but I don't think so. Especially if it requires possibly complicated server and client-side components...

My (limited, so far) look at google wave gives me a bit of hope, but only if it can give rise to software people want.

I personally think the only thing that could best email would have to provide everything Microsoft Exchange/Office/Sharepoint/Etc. provide (or claim to) but do more and do it better, and have available some really stellar clients/interfaces.

I'm talking person-to-person messaging, group discussions, shared calendars and scheduling, document sharing and collaboration, linking between various entities, and also end-to-end authentication and authorization, all with as little  centralization as email, or nearly so...

It's a pretty tall order.

Google Wave seems it could be capable of much of these things, but since I haven't used it I can't say what it's got already. What does it take to run a server? How much work does a client have to do? Is the protocol completely open? Is the API any good? How does it scale in various use cases? How easy is it for users to get done what they want to do?

If it is easy to do things... how do users keep from getting buried in information like we all are with what we have now?

And the big question - will anybody actually write Wave software that's compelling enough to convince users everywhere that they should use it instead of the trusty standby of email?

Lots of questions, and few answers, but true to my geeky self, I still get excited over the possibilities shiny new systems bring.

Friday, October 9, 2009

Abstractions and Usability: When Practicality trumps Sophistication, both sides can win.

Something I think about a lot are abstractions. There's a lot of abstraction in programming and sometimes it's healthy, and the sign of good design and thinking.

But more often than not, I find the layers of abstraction become confusing, limiting, and frustrating.

Some recent discussion with a friend with whom I have been coding made me think some more about just how much a powerful, flexible, ingenious set of abstractions can lead to software that is unusable by the intended audience.

I am hoping we go with a simpler, more consistent architecture that uses small, easily-understood concepts. It may be harder to say it's "enterprise grade" without the fancier ideas, but I think it will be both easier to build and easier to use.

This isn't of course a Perl-specific problem, but we're in the design-stage of a Perl application that will require the ability to be customized in ways we will probably never imagine!

No matter what architecture we end up implementing in order to provide a product, if it isn't immediately useful, and easily understandable by the target user audience, it can not succeed.

That makes me think about what makes a language successful... Perl is a great example of a language that shares the ideals I want in this application! It should:
  • be easy to get started for simple uses
  • be easy to transform simple uses into more complex uses
  • provide functionality that users will need to easily get common stuff done
  • provide functionality that users will need to customize generic tasks
  • allow users to easily add custom functionality
  • allow users to share and re-use custom functionality
  • be flexible enough to allow for different ways of thinking about solving problems - whatever the user finds best for *them*
  • make possible the creation of sophisticated systems - that can then easily become part of other systems.
I really see these goals as very Perlish in nature: The people that will use this software do not want to babysit a system, nor do they want to become gurus on its internals. They do not want to care about rule-sets and mini-languages and asynchronous message-passing data-flow systems...

The just want a system that is immediately useful and easy in simple cases, but allows and encourages them to grow it into something much more powerful over time, without forcing upon them layers of new abstractions or solutions that feel unnatural and inflexible.

Perhaps I'll write more about this specific application soon... I've been reading The Mythical Man Month and it's lit a fire under my rear on actually making this thing a reality... I now want to start not with code (of which I've already written some) but with a design document detailing how an end user would see and use this system in the most common cases.

I believe that software should always be written for the users, and making the program (or language) easy to use yet still powerful and flexible is the highest goal for which a programmer can strive.