Mar 28

How did enterprise get into the cool kids locker room?

Java, Tech 3 Comments »

Dead Coffee

I have seen a number of threads, over the last couple of years, where people claim that “Java is dead” in some fashion or another. You could argue forever on what that actually means. Java the language? Java the platform? You mean EJB? Do you realize how many people are writing Java code?

What I find more interesting, is thinking about how the enterprise folks were sexy for awhile and crossed over to the consumer side.

The cool kids these days are talking about things such as:

  • Erlang
  • Django
  • Neo RIA
  • Microformats and DSLs
  • iPhone SDKs
  • Social APIs

Not so long ago, the same people were hacking away using Java. And not just Java, but enterprise Java! J2EE folk who may have written an EJB or two. Back in the day this was sexy. How the hell did that even happen? It just doesn’t seem right :)

Mar 28

Social Web – Web = 0

Tech, Web Browsing with tags: No Comments »

I heard the term “Social Web” too many times today. It is the type of term that can bug you a la “Web 2.0″. What the hell do you actually mean? Just like everything else, the Web itself will consume any of the good thoughts on the meme, and we will make fun of the term more and more.

Although a lot of thought is placed around social “sites” and putting little applications on those sites, we will quickly move away from this model.

We only have to look at the past to see this.

Islands

Do you remember life with AOL and Compuserve back in the day? We had the walled gardens where they controlled the content and the entire experience. When you have that kind of control you can do interesting integrating, but we moved away from this as soon as we have the building blocks that were required to move us. First we had Gopher, which failed partly due to greed (charging for server licenses) and partly due to functionality (ridged folder based structure), and then we got the world of the Web including HTTP and HTML.

Tim Berners-Lee managed to unify fresh islands using hypertext (as many other systems had before) in a very simple way. The decoupling of client and servers started the viral growth, starting with academia but quickly getting into the commercial world.

With HTTP and HTML acting as the bridges, what about the cars? We started with very simple browsers, with Mosaic being the first big one that added features to what it would understand in HTML.

When we skip forward in time, what do we get to drive now?

  • Internet Explorer: This is the Ford of browsers. Good ‘ole American made, highly marketed.
  • Safari: Coming from Apple this is maybe a clean BMW?
  • Firefox: a GTI that I can pimp?
  • Opera: A euro-SAAB?

We do not have a huge choice on the type of car that we drive, but at least they have opened up on how much we can tinker with them. Firefox lead the charge with its plugins/add-ons and now the others have some form of this.

Being able to tweak my experience via JavaScript technology is empowering. You don’t need to be a hard core C++ hacker to do some tweaking, and again Firefox breaking out to give us the XUL approach was fantastic.

As an extension point, plugins are OK, but are also too much for many people, and can be a pain to manage. What if I want to tweak something of my experience on a Web site? This is of course where Greasemonkey came in and truly empowered people to take over their experience. They could grab a Greasemonkey userscript that would let you use Amazon to find things, but also show you the price from other stores. Amazon.com became the meta search engine.

I find it painful when I jump on Gmail on someone elses computer as it doesn’t have my Greasemonkey extras, let alone if you use something like GTDInbox that drastically changes the experience.

This is about the user taking control of their world. Gears on the other hand is about giving the Web an update mechanism, allowing developers to extend the Web platform to do new tricks.

All great, but we need more. Even though the Web is open through HTML and HTTP, it isn’t reving fast enough, and it doesn’t feel like we are moving forward as fast as we could.

What would it mean if we take some of the characteristics from the social networks and put them into the cars themselves instead of just in some islands?

Me.dium is trying to build a social Web experience. So far we have seen the plugins and widgets that allow you to chat and explore the Web together. That is somewhat interesting, but I would love to take it further and have the service give me a personal TechMeme based on my friends.

For me, it keeps coming back to social extension points. There are hundreds of Greasemonkey user scripts out there, but you never know about it. Only the die hards are going through userscripts.org. Could we do better and have:

  • Social notifications that tell you when extension points are available. “There is a script that would allow you to do X on this site”
  • Have the scripts weighted by my social graph, or the wisdom of crowds (narrowed by my graph a little), or other algorithms

The end result would be a push of interesting behaviour that is created and added to sites other than those who run the actual site. The comprimise here is that we have to deal with security, and gaming the system.

I would love to see the citizens having the power to change the Web in this way, so maybe it could happen. No more social networks. The Web would be implicitly social. I need to think more about explicit extension points that sites could put out (so it isn’t about monkey patching).

Mar 27

Gears as a bleeding-edge HTML 5 implementation

Gears, Tech, Web Browsing with tags: 7 Comments »

Gears and HTML 5

Above is a slide from one of my Gears decks. I get a lot of questions around Gears and HTML 5, and I wanted to be explicit about the role that each play, and how excited we are about HTML 5 (and other standards in fact).

I do not see HTML 5 as competition for Gears at all. I am sitting a few feet away from Hixie’s desk as I write this, and he and the Gears team have a good communication loop.

There is a lot in common between Gears and HTML 5. Both are moving the Web forward, something that we really need to accelerate. Both have APIs to make the Web do new tricks. However HTML 5 is a specification, and Gears is an implementation. Right now you can see differences between the two. I overheard a good analogy for this in a meeting this morning. You can see how similar parts and pieces are, and it will be natural to bring these together just like the image above shows the sides of a zipper.

It is my belief that HTML 5 and Gears will converge in the not too distant path. This has already happened a little, as the WorkerPool API has been proposed to be added as a standard. We are also working on converging the database APIs, with great work from Dimitri Glazkov. To be clear, we have actually been working with the HTML 5 group (starting with WHATWG) from the beginning, but life isn’t perfect and it can take some time to converge.

Standards bodies are not a place to innovate, else you end up with EJB and the like. Instead, they are a place to take work that is already being done and spreading it out. Hixie is doing just that. He studies the Web, how it works, and then works with everyone to come up with nice general standards. HTML 5 is also a large spec that has some additions that do not make sense for a Gears plugin, items that are low level browser features that we couldn’t touch. All implementations of specs are not perfect, and thus we know that Gears will not have exactly the same implementation of HTML 5 as others. On the other hand, Gears is always going to be a superset of HTML 5 as we are pushing the Web hard and innovation is key.

Gears came out of the real-world need within Google to create more and more compelling Web applications. We took Google Reader offline and learnt along the way. We saw the pitfalls, wrestled with synchronization issues, and along with other applications came out with the first release of Gears last May. Now we work with ever expanding groups at Google and learn from their needs, and since we went public in May, we have gotten to learn from you folks.

Gears is a battle hardened Web update mechanism, that is open source and ready for anyone to join and take in interesting directions. Web developers get to go guerilla and fit issues that they see. The good ones? We can bring them back to the HTML 5 standards party.

I guess the zip will always be opening and closing. For some APIs (Database and such) we will join at the hip, and then as we come up with new ones we will break away again and the innovation will start.

My hope is that we will constantly be coming back together.

When you view Gears through the lense of “A bleeding edge implementation of HTML 5″ that is also battle hardened since it has to be deployed for Google (so it isn’t an experimental toy!) you can also see how different it is to AIR and Silverlight. They can play together just fine, as the future of Gears gets into HTML 5. This means that WebKit will support it, and Gears and AIR will be together in that world. Hopefully the IE team will continue on their standards march and you will see the same there. It is nice to see a world where you can work together instead of make stark choices.

The first post I read this morning was Alex Russell giving some more thought to the future of the Open Web where he concludes:

Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.

At this point in the webs evolution, I’m glad to see browser vendors competing and I still feel like that’s our best long-term hope. But we’ve been left at the altar before, and the IE team isn’t giving us lots of reasons to trust them as platform vendors (not as product vendors). For once, we have an open, viable Plan B.

Gears is real, bankable progress.

Oh, and @simonw, I am with you. I want to see that too.

These are my personal opinion and may or may not be that of my employer

Mar 27

A different kind of container

Comic, Tech with tags: No Comments »

Containers

It is fun to see the wheel turn around again. I remember when EJB containers were the cats meow, and now when I hear someone say “container” in a meeting it is a social one.

I am happy to see some innovation from the Orkut folks. I have often been frustrated when I have clicked through something and been asked to install an application when I just wanted to see something simple. It makes me so mad that I never say no!

With OpenSocial, it’s possible to create environments where applications can spread because they provide great user experiences. The metric for success would be not the number of installs an application receives, but user engagement and happiness. Environments that focus on more than viral growth cultivate healthy, organic growth and usage. This contributes to the long-term sustainability of social platforms for both users and developers.

To that end, you’ll notice there are a number of functions in the OpenSocial API starting with “request” (e.g. requestShareApp, requestSendMessage). These functions define an agreement between the applications developer and the host container that allows the container to optionally prompt the user for more input, or simply deny the request. While each container will be able to define its own policy, we encourage apps developers and containers to take advantage of these functions to create an “install-free” user experience.

Mar 26

How FriendFeed could dwarf Facebook and Twitter

Tech with tags: , , 14 Comments »

The River

When FriendFeed first came out it looked like a nice little aggregator done by some smart EIRs who just left Google. A few months later they have grown into being the company that is mentioned on TechCrunch, RWW, TechMeme, and Mashable on a daily basis. Quite a change in a short period, so with the launching of their API, I thought I would posit how I think that they could keep on going to much bigger things, and above the hype cloud (everyone wants the next Twitter).

As I look at how I use these services, I have noticed some recent changes:

Stage 1: Really?

I did the Twitter thing when it first came out, and I admit to not getting it. I remember opening up the public view and seeing the odd swearing from Bulgaria and thinking “this is 99% noise, why does anyone waste their time?”. After a Twitter week I kinda moved on. The most I had to do with it was using MoodBlast to send my status updates to Twitter too.

Stage 2: Facebook

I moved from Twitter to Facebook and got much more attached to it. “My crowd” was on their from the tech side, and a bunch of old mates from England too. I got to get up to speed with their lives, and over time keep in touch in that tiny way by the status update, and the odd photo.

I saw huge value in being able to learn from my friends, and dreamed of being able to have my own personal Digg, centering the bell curve on me instead of 12 year olds.

As applications were getting built I was excited to see what “killer apps” will be thrown up on the Facebook platform. Scrabulous was the one I used the most, but I saw far too many Vampires around and kept seeing my notifications list on the top right go up to huge numbers as I couldn’t be bothered to say “No” to them all. I could ignore that though, and still saw value.

Then something strange happened about a month or two ago. The feed started to get less interesting. Note, all I use Facebook for is the feed. I am not someone who jumps around on profiles to find out if Jinny has has a relationship where “it’s complicated”. My feed was getting noisy, and there was less in it. The magic had gone. It seems like the core group that I care about isn’t doing as much on Facebook, so the viral nature in which it erupted has reversed just as quickly. My Facebook tab disappeared and now I can’t remember the last time I logged in.

Stage 3: Twitter part deux

“Twitter is chat where I don’t care about a response”

As Facebook usage was going down, I was also back to Twitter and finally got it. I hit the right sweet spot of following and followers and saw a lot more signal coming through. I stopped using MoodBlast and turned on the Twitter Facebook application, even though I was annoying people with the “is twittering” part of the messages that drive me nuts (Twitter: please let me turn that off!). I guess I should switch to TwitterSync, but I just don’t care.

I have started to get a lot of leads for Ajaxian and cool tech in general on Twitter, and it is a place to call out into the void and you often get a crazy number of responses.

I am starting to wish for more though. Firstly, stability of course. But then, I want features like #hashtags to be grokked by the platform, so they don’t take up valuable characters out of the 140, and that the UI deals with them accordingly. I would love a metadata layer that would allow for the payloads that dave whines so much about, but also more. Let me put in [lat: ..., long: ...] to add Geo. Let me add anything I want and then the apps on top of Twitter are sure to shine. If Twitter doesn’t do this, I think that over time other services will fill that void. Pownce is ready in the shadows, but it needs to be more than Twitter+1. This is where FriendFeed comes in.

Stage 4: FriendFeed = Twitter * 2

FriendFeed is adding cool features on a weekly basis. I have personally worked with Bret Taylor and he is top notch, so I have no doubt that this will continue. A team that has launched Gmail and Google Maps also groks scalability, so I do not expect them to have the same troubles as Twitter.

But then we have the features. I think they can be a great mix of Facebook and Twitter. I want the stream to be more about just chatting. I want the photos to be part of it. I want my personal Digg. I want….

Stage 5: The River

It keeps coming back to my desire for The River, a new email system for all activity.

The key to this is having enough dials to make it tunable. With every feature that FriendFeed adds, they seem to get closer to this. Search is key as it gives you the nob tuning on the fly, and the API is key as it could let someone like me actually implement something that I need.

Here is to a FriendFeed that keeps accelerating. Congrats so far guys.

Mar 26

Imagine what you could do if you helped your users?

Tech with tags: , , 1 Comment »

Computer Help

Context is everything. The context for an online help system for most companies is that they want to do everything possible for you NOT to contact a human being. The CIO looks at the numbers and call/email centers as a money pit in their eyes.

I just had yet another example of this. It is a common one.

I had to contact United and didn’t want to jump on the phone to hate life in the automated system as I type “0″ as often as I can to get a human that will be on the other side of the world.

The issue wasn’t mission critical, so I wanted to just shoot off an email. Along the way the system tried really hard to trick me into not sending it, culminating in this:

Resolve Issue

The key is that after you click “SEND” you expect the email to be sent don’t you? I do, and as it is loading I move on from the tab as I am done with my action. When I run across the tab later I am surprised to see “Here are some answers to your question” with a “Continue sending email »” message. Oh darn it, now PLEASE actually send the correspondence would you old chap?

If the systems that try to work out the solution to your problem are awful. They have never actually found the answer to my question, and if my question was simple enough I would have found it on the site or through simple usage. Most of the time you are asking someone to add your frequent flyer number to a reservation (when you try it errors out) and you get back “Do you want to rent a car?”

The system could do a much better job by:

  • Actually giving you results that make any sense at all, and if you don’t think there is a good match don’t even try
  • Send the email, and then say “hey, just in case, was it one of these?” On the bizarre off chance that they got it right, there could be a button that would cancel your question “You don’t need help anymore, thanks though”

If the CIO actually realized how important customer service is to the brand and the entire experience, this enlightened person would be able to do so much good that you wouldn’t be able to switch to the competition.

Imagine:

  • There is a 10 minute wait, but don’t worry, we will call you back, so get off the phone
  • I am sorry that the connection died, I called you right back
Mar 25

Upgrade the Web: Time for UDP in the browser?

Tech, Web Browsing with tags: 10 Comments »

The Pipes

We tunnel everything through HTTP these days. Poor old port 80 is the backdoor through the firewall, but the hole is small and only truly suited to certain protocols. One of the crazy wrappers is taking streaming video and putting it in the HTTP envelope. This is nuts as HTTP is of course running on TCP/IP which gives you reliable ordered packets. The overhead of making sure this is the case is large, and is not needed for fire and forget type applications. Video, VoIP, gaming, they all favour UDP as you just want to shove bytes down as fast as you can and if you miss a packet or two it doesn’t matter, you are onto the next.

Wikipedia tells the tale:

Difference between TCP and UDP

TCP (”Transmission Control Protocol”) is a connection-oriented protocol, which means that upon communication it requires handshaking to set up end-to-end connection. A connection can be made from client to server, and from then on any data can be sent along that connection.

  • Reliable – TCP manages message acknowledgment, retransmission and timeout. Many attempts to reliably deliver the message are made. If it gets lost along the way, the server will re-request the lost part. In TCP, there’s either no missing data, or, in case of multiple timeouts, the connection is dropped.
  • Ordered – if two messages are sent along a connection, one after the other, the first message will reach the receiving application first. When data packets arrive in the wrong order, the TCP layer holds the later data until the earlier data can be rearranged and delivered to the application.
  • Heavyweight – TCP requires three packets just to set up a socket, before any actual data can be sent. It handles connections, reliability and congestion control. It is a large transport protocol designed on top of IP.
  • Streaming – Data is read as a “stream,” with nothing distinguishing where one packet ends and another begins. Packets may be split or merged into bigger or smaller data streams arbitrarily.

UDP is a simpler message-based connectionless protocol. In connectionless protocols, there is no effort made to setup a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction, from source to destination without checking to see if the destination is still there, or if it is prepared to receive the information. With UDP messages (packets) cross the network in independent units.

  • Unreliable – When a message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgment, retransmission and timeout.
  • Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.
  • Lightweight – There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP.
  • Datagrams – Packets are sent individually and are guaranteed to be whole if they arrive. Packets have definite bounds and no split or merge into data streams may exist.

What if we had nice UDP support in the browser itself, something that could fall back to HTTP if necessary. You would need that to make sure that the firewall gods wouldn’t stop things working, but think of the YouTube traffic and how much better streaming video would be! And games! And, Skype!

Can we do it, or is there too much inertia around “HTTP won. It’s good enough”

Mar 24

Upgrade the Web: Do you want your browser to Jabber away?

JavaScript, Tech, Web Browsing with tags: , 2 Comments »

Old Men Talking

Aaron Boodman was probably right in thinking that me wanting OpenID in the browser makes more sense as a browser feature, or separate plugin. This is a consumer level feature more than a developer focused one.

As I ruminate in the world of wishful thinking, I started to wonder about Jabber, and how it would be interesting to have XMPP as a native browser protocol.

We do have Jabber plugins, and there are JavaScript libraries that implement Jabber, but shouldn’t this be in the browser?

Jabber seems to be popping up all over the place. It started off as the IM protocol, and now has become a generic, scalable, messaging system. If XMPP was native and reliably in browsers, imagine how it could help the chat in Gmail? It could also transform the chat relationship with the Web. Social browsing as Me.dium does it could become more integrated. For example, I could have a trivial way to enable group chat on Ajaxian. I would love to be on the site and have others who are on there tell me how things are going, give me tips, and have comments feed into the same system. I shouldn’t have said “enable” as I wouldn’t have anything to do with it.

At an API level, we could also access XMPP from JavaScript.

Hmm, actually, is there a way in which this could tie into single sign-on and OpenID? Could XMPP be the way to login?

Mar 20

It’s just my email password…

Tech with tags: , , 3 Comments »

Security

I couldn’t help but interrupt someone at the coffee shop as I saw them giving their Gmail username and password into some random third party system to “grab your contacts”.

I get why sites have been doing this, but now we have the Google Contacts API there shouldn’t be the need.

What astounded me was the logic that this fellow used. He talked about how he used really good, different passwords, and never kept them in his email, so if the third party site was malicious they wouldn’t get anything good.

He didn’t seem to realize that by giving away the key to your email account, you are doing a LOT more than letting someone look at that email to your mum. With it, they have the keys to your forgot password? life. They can quickly go to accounts that you have all over the shop, simulate a forgotten password use case, and now they DO have access to your account info.

It isn’t about what is in your email before hand, it is the access to future email that matters.

This is why I was over the moon when the contacts API saw the light of day, and I hope to see all providers do similar work.

Mar 19

Gears Future APIs: OpenID and OAuth

Gears, Tech, Web Browsing with tags: , 14 Comments »

Single Sign On

When I was looking over Brad Neuberg’s Paper Airplane thought experiment I noticed the single sign on feature, where you login to the browser, and then you are done.

I realized that this is what I actually want. Having one signon via OpenID is really nice. It allows me to plug in “http://almaer.com” as my identifier. However, I always have to go around finding the OpenID option (if it exists) and put that in.

What I really want is for the browser to do that work for me. If a site groks OpenID the browser should be able to pass that over without having me intervene at all. It could hide the entire login process if we came up with a microformat to let all sides know what is going on.

It would be a breath of fresh air to be able to jump through sites leaving comments on blogs, and checking out my todo list, all without me once having to actually login.

I wonder if a Gear could be made with a complementary microformat / server side handshake that could then give us single sign-on in all of the browsers.

As Brian McCallister suggests:

<link rel="openid-auth" href="..." />

Other Future APIs

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.