Wednesday, April 17, 2013

Features of a Good Cloud Operating System

I'm a fan of "the Web." I drank the Web 2.0 Kool-Aid and believe in the Internet's ability to dis-intermediate, disrupt and enable.

I like "the cloud" even though I know most ASPs are probably storing my password in the clear or hashed with MD5.

I live in fear of the day Google decides to switch off Google Docs or Google Music. I worry that I sometimes depend on services that fail a year after launch.

I'm a "lead user" living on the bleeding edge of technology. Stuff *mostly* works, but I wish I could stop worrying and love the web.

I've been waiting for other people to build software that makes me less nervous, but I'm starting to get tired of waiting.

I want to build a "Web Desktop" that lets me keep my data where I want to keep it and display data the way I think it should be displayed. Here are a few ideas I'm kicking around for software I'm about to build.

Idea 1 : I decide where it's hosted

I know this isn't an answer for everyone, but I don't mind too much if I have to put up a server. Heck, I might just load the software onto a Raspberry Pi and serve it from my house.

If someone hosts the software I write for me and charges me a couple bucks per month, I'm down with that. As long as they're trustworthy and clueful.

Idea 2 : I want to see a dashboard instead of a screen saver

When I wake up in the morning, I would love to see a Dashboard on my Roku screen. Or as my laptop's screen saver. Or whenever I hit F1.

What I put on my dashboard will be:

  1. Today's Calendar
  2. Weather info for the next two or three days (but certainly for the next twenty-four hours.)
  3. List of the top five "To Do's" (both personal and work.)
  4. Upcoming deadlines or important dates.
  5. The "Has North Korea Nuked Austin Yet" indicator.
  6. Traffic information about my commute.
The web app I'm going to build will be something like a "dashboard construction set" so you'll be able to put stuff you like on your dashboard. I don't really track my Klout score and could care less how many friend requests i have outstanding on Facebook. But that might be important to you, so I'll figure out a way to do that. And I'll build a simple widgety client thing so other people can build dashboard widgets. I probably wouldn't have to do this if JavaScript widgets didn't suck on Linux (and let's not even mention how they disappeared from Windows.)

It would be super-awesome if I could make it with different dashboard layouts for 1920x1080, 980x1228, 600x800 and 320x533.

Idea 3 : It's about the context, stupid!

Why is this such a difficult concept for software vendors to grok. I am more concerned with "context" than with apps. or documents. "Context" is not about tools, but about tasks. "Context" has less to do with workflow artifacts and more to do with "Who am I doing something for?" It's also about understanding what I'm willing to be distracted with.

What does this mean in practical terms?

First off, I need multiple virtual desktops (or webtops, since I'm implementing this in a browser.) When I'm in the work virtual webtop, I don't want to see facebook updates. I don't really want to see personal email alerts. I'm happy to take calls from my family, co-workers and my child's school, but that's about it. In my personal virtual webtop, I only want to see work email alerts for "important" emails.

And most importantly, I don't want to see either a grid of applications OR a grid of documents, I want to see application AND document icons.

And when I open a document in the work webtop, it should stay in the work webtop, even if i switch to the personal webtop.

To me, context is about:
  1. Things I do
  2. Things I do it to
  3. Who I do it for
  4. What I'm willing to be distracted by
Idea 4 : No. Really. It should work everywhere.

It's unlikely I'm going to write a twenty page document on my mobile phone. I would like to be able to open a document, search for the word or name I just realized I mis-spelled, fix it and save the document back to the cloud.

If it works on the desktop, it should work on the mobile phone. If I'm stupid enough to try to edit documents on a mobile phone, I have larger problems than some product manager worrying that it will be a sub-par experience.

Idea 5 : Well-Defined APIs would be nice

In the glorious future, when we have our Internet of Things, we're going to get data from all sorts of little devices. It would be nice if they spat out data in well-defined, possibly self describing chunks. Things they speak to should have well-defined APIs. I want my car's gas tank meter to send data to my dashboard app so it can wake me up 15 minutes early 'cause it knows I'm headed to San Francisco tomorrow and I don't have enough gas for a round trip (ergo, I have to hit the bio-diesel station on the way into the city.)

Idea 6 : Apps should "play nice" with the dashboard.

To the degree it's possible, I would like widgets and UI components for apps to bundled up and delivered to my user agent (web browser) as discrete chunks. I want to be able to set a theme (like large text, high contrast, etc.) and have that theme be honored by widgets and app UIs. Yes, I understand this means I'm going to have to have a reasonably robust and potentially non-css styling language. I hope I can just get away with LESS stylesheets run through handlebars templating.

Idea 7 : Data and code come from anywhere

Yes. I know. It's an XSS attack waiting to happen. But I'm confident I can code safely, especially with the Content Security Policy API coming down the pike. Maybe in the future we'll have a reputation service instead of an app store. Before you install an app, you can automagically check with your constellation of reputation providers. That way the devout, morally straight Mormon down the street can point to the LDS reputation service to prevent his kids from downloading the Suicide Girls calendar app, while I can add the Wicked Grounds recommendation service to my list of app reputation providers.

Idea 8 : Maybe we could have accessibility features that don't suck

JavaScript heavy applications have the reputation for not playing well with screen readers. Maybe we could include a text to speech renderer in the system and convince app developers to expose data to the renderer. In the glorious future, we're bound to have web apps working on mobile phones in cars, so a voice API might not just be for the vision impaired, but also for drivers who want to work hands-free.

Other features like high contrast and large print themes should also help the over forty crowd.

In Conclusion...

So... I haven't started on any of this yet, so feel free to chime in. I'm mostly spitballing ideas, but I'm going to start coding tonight. I'll come back in a couple days with a pointer to a GitHub repo and a few notes. Cheers!


No comments:

Post a Comment