It was bound to happen sooner or later – paradigm shifts demand it.
Old technologies do not disappear from one day to the next, they get assimilated, until it’s hard to understand where one stops and the next begins. Sometimes this happens overnight, and we don’t even notice what has happened.
A few months ago – not many in terms of “real life” hours, but an eternity in Second Life® – a brief discussion with Linden Lab exposed the rumour that they were planning to integrate an HTML browser inside the Second Life application client. This is not a revolutionary breakthrough – things like ActiveWorlds or OpenCroquet have done it ages ago, and the world did not shatter and end at that time.
Some eager residents of SL were happy about the idea. At the very least, you would be able to exchange notecards with “rich text”. Perhaps even have a way to browse a bit while in-world – no more need to open up your browser to check the Help pages, do some forum posting, or even insert events directly from in-world.
On a second stage (according to Linden Lab®), HTML may be directly drawn on top of a prim face. This would mean, for starters, a way to get outside information on top of a 3D world. Older platforms already allow for this usage of HTML. Things like proper text management on top of a prim are finally possible – books, slide-show presenters, scoreboards, even clothes vendors, will be able to get away with textures for writing text, and use HTML-rendered text instead.
The third stage is full integration. Prims with HTML pages (and LL is still thinking on how this will happen) will be point-and-click browseable. Neither we nor Linden Lab have yet figured out how exactly this will be implemented. Apparently, Second Life has the ability to define with a certain degree of precision where exactly – pixel-wise – you can point your mouse and click. Unfortunately, due to the mechanisms at the renderer level, this kind of interaction is not “visible” at the Linden Scripting Language level. This means that eventually the system may “know” where you are clicking, but you only get told which prim you’ve clicked. Being able to click on part of a prim is what you need to have a clickable browser, fully able to reply to hyperlinked text. And, of course, a way to fill forms (on a prim?) will need to be thought out as well.
The technology is not too hard. After all, it’s not if Linden Lab is developing everything from scratch. They’re simply integrating Mozilla technology – open source code that came from the Netscape days and is currently being used on the Firefox browser, Internet Explorer’s most direct competitor (although with perhaps only 5% users). Gecko, the Mozilla rendering engine, will be part of the Second Life browser. You can think of that as a “plug-in for Second Life” – so, besides streaming 3D content, your “Mozilla plug-in” will be able to deal with hyperlinked 2D content as well. We’ll explore this model in a bit.
Hiro Pendragon, in his own blog The Second Opinion, takes a look at this Big Change in Second Life, mostly from a technical point of view. Basically, what Hiro means is that the changes are going to be monumental and spectacular – all point towards a reduced usage of prims and textures in SL, allowing people to use HTML embedded into 3D objects to replace current “workarounds”. Imagine a Web-based vendor: one prim, you see the pictures, click on the page to see the next or previous one, pay the object and get in-world delivery. One prim, no scripts, no hover text, no open listeners – no lag at all! That’s what currently people like FlipperPA Peregrine (programmer for SL Boutique, one of the off-world e-Commerce sites) are working on. Laggy shops and malls will once more become fun places to visit!
There are lots of more possibilities: casino machines which will work the same way, or vehicle controls, bank ATMs, or the whole InfoNet system, as well as slideshow presentations using textures, or in-world books. As a matter of fact, all sorts of information-based objects will use HTML-on-a-prim of some sort.
So, this will reduce the amount of prims, textures, and scripts with “open listeners” or similar lag-inducing features. Add Havok 2 and the new 2.0 renderer, and this is what Second Life will look like:
… with the same 15-25 fps that a “normal” machine is able to render.
Some may be worried about the performance issues of Second Life, when it grows to “embed” the Gecko HTML renderer from Mozilla. As a matter of fact, Second Life’s client will probably become smaller. Here is the trick: all information-based dialog boxes will be replaced by their HTML equivalent. With proper Web design, you won’t be able to distinguish them from the current dialog boxes.
Prime candidate is, of course, the “Find” dialog boxes. As you may have noticed, most of the functionality is available (even if on a limited way) on SL’s web page as well. So, things like who’s online, available land for sale, what transactions have been done, the many many help files, and, of course, the event list, are currently “web-enabled” already. The only thing you need to put them inside SL is to simply change their appearance to match SL’s “white text on anthracite background” look.
The common player won’t notice a difference, but the amount of flexibility is tremendous. Robin “Linden” Harper, VP for LL and handling the SL Community, has often explained the patient residents that developer time is very restricted for new features on the client – but Web development is easy to do. So, this means that all developers can concentrate on the 3D viewport, and have the Web team change the 2D information-retrieval facilities inside SL. And they’ll be able to change that without releasing new patches. Just think of it: new changes can be done by simply rearranging a few lines of HTML server-side, and the interface can be dynamically re-arranged! You log in again, and all the dialog boxes have been “improved”.
If cleverly done, this will mean much more than the “Find” dialog box. The whole Instant Messaging system can migrate to a Web page as well. Scripts and Notecards can be written on an HTML editor (and currently there are so many cool alternatives using Javascript, so no need for extra coding), and, when you save them, the text goes into the asset server. Eventually, if it’s very carefully done, even the infamous Inventory could become a Web page with clever Javascript and all the nifty new features of cascading style sheets to deal with opening and closing folders.
The way you can make a Web page interact with your 3D environment has been explained by SL developer James Linden. When you embed the Mozilla code into an application, you can develop Web pages that “call” things in the application itself. This means that you could put Linden Scripting Language (or whatever will be available soon as a replacement) calls inside Web pages. So, the Web-based inventory would be able to do all the folder/item tracking using HTML-based programming; but, as soon as you need to transfer an outfit on top of your avatar, or rez in an object, you’d call a function from LSL – from inside the Web page! – which will take your work from there (I imagine that the only thing you need to do anyway is to keep track of the item’s UUID).
This sounds like replacing one way of programming by another. But it’s far more than that.
Imagine that you could call those in-world Web pages from another browser – outside SL. So, things like IM, inventory browsing, or buying and selling land, could be done on a normal web browser. For those of you fortunate enough to have two monitors connected to your computer, this would mean having one of the monitors dedicated to the 3D viewport, the other for the multiple dialog boxes that clutter up your windows (no more missing your friends when you’re busy scripting!). It would also give you some sort of a “limited SL experience”, like being able to chat when not logged in, or even being able to send items to other people.
This shouldn’t be too hard – after all, a web page will be a web page, you will just need to do some authentication (like you do nowadays for the SL web site anyway).
But the more interesting aspect is that you can do things the other way around. People have been complaining about limitations on “flat” interfaces – like, say, the console system of a vehicle, or multiple options on dialog boxes that let you easily pick up choices, instead of creating multi-prim objects with dozens of tiny prims just to be able to click on them. Now you can touch on an object, and you get a floating Web page with all available commands – no need for opening a listener, or demanding more interaction tools on the “command pie” menu besides sitting or touching. As you see, this will allow you to extend your user interface easily this way – something that has been asked for ages, since the dawn of time, and that never was so easily and conveniently offered, but which is now possible – even perhaps for 1.7, taking into account the “limitation” that the first version of in-world HTML will always be on a separate window, and not on a prim’s face.
So, Linden Lab is effectively giving people a way to change their interfaces at will, and extend them by using in-world objects which pop up new windows. This is really very clever.
The biggest change, however, is not going to be either of the above items. The biggest change will be another major paradigm shift – and SL is already so good at redefining those!
Whenever I talk about the similarities between Second Life in 2005 and the World-Wide Web in 1993, I’m astonished to see how many people have completely forgotten the pioneer stages of the WWW. I feel that I need to go back 12 years or so and refresh the memories of many – and still, they will fail to understand the analogies.
The World-Wide Web started to be a text-based web. Content was important for Tim Berners-Lee, credited as the HTML/HTTP inventor – and not design. WWW was an alternative to a few content-retrieval systems that were around, most notably Gopher, which had a similar purpose at that time. But there were really dozens of similar systems around, based on Bulletin-Board Systems, that you could (in some cases) access via the Telnet protocol. All text-based. All were different from each other. The point was, there was not a “web” of information – but isolated systems in the Internet, each one being accessible in a different way, although, from the comfort of your office, you could access them all remotely through the Internet.
So the WWW was just “the latest” online system. But two things happened very quickly to the WWW – by chance, perhaps. The first was the graphical browser, Mosaic. This was a huge application, incredibly heavy, which consumed all your poor computer’s processing power, and which allowed you to see things like GIFs and text rendered with fonts, as well as being able to use your mouse to click on hyperlinks.
The reaction of many was twofold. The visionaries would say: “wow, this is the killer application that will bring the Internet to the masses! Graphical browsing! No silly commands to learn! Yay!” Most of the people at that time were much more skeptic – they said “nobody will launch a multi-megabyte browser just to see a few nice pictures”.
Of course, from our privileged point of view in the future, we know who won that argument.
Still, the skeptics did not stop at that. They claimed – very wisely – that without any sort of input, the alleged World-Wide Web would be worthless. It would be mostly static content, and there is limited interest in viewing other people’s home pages. Sure, there was some appeal in that, but the WWW would be a minor fad, and quickly disappear.
The second radical change was the Common Gateway Interface (CGI). This was a trick done server-side – with some help from the graphical browser – to be able to put forms on the Web page, and you could send the values inserted by the user to the server, which would render – dynamically – a new page for you.
At that time, people discussed the impact of a graphical Web browser with form-sending capabilities lightly. Ok, we could now do remote phonebooks: select a page, insert a name, and the system would retrieve a card from a database with that name’s phone number. The first “web-enabled applications” were not much more than toys.
But then things started to become serious. The graphical browser started to be able to “talk” other protocols as well – things we take for granted nowadays, like FTP, and outdated protocols that we don’t use any more, like Gopher or WAIS. But you could also read the Usenet News online that way (for those that never used the Usenet News, this is a free, 30-year-old, multi-million-user forum with hundreds of thousands of separate group forums, that sadly has gone out of fashion).
And suddenly – literally from one day to the other – more complex applications started to be developed. Things like Yahoo – which started out as a list of cool web sites to visit, sent to you by email periodically – became “catalogue sites”. The phone companies put Web pages online where you could look up the white or yellow pages. You could start to shop for travel flights, or books and CDs. All this was not done from scratch, these systems already existed. The “WWW revolution”, at the beginning, was just to put “new clothes” in front of an old product.
The phrase “web-enabled applications” was coined. Suddenly, the WWW was not so much thought as a network of static content, but rather as an universal interface to billions of applications “out there”. You just needed to do the application, and forget about the user interface – everybody used the same browser (or almost 🙂 ), so you just needed to put a nice HTML wrapper in front of your code, and the application was ready to be launched world-wide.
This was the “web revolution” – an universal way to interact with all sorts of systems and applications, from a common interface.
Now, as the web revolution progressed, new tools, systems and services were employed and incorporated into the Web. Streaming, for instance – something very dear to Linden Lab’s CEO – would never had “taken off” if you hadn’t a way to pick your stream from a web page. But more broadly speaking, nice buzzwords from the IT folk like e-Commerce, e-Learning, e-Marketplaces, and whatever you fancy to name the next e-Business – would never exist if it weren’t for this simple fact: you have an universal interface to all those very complex systems and applications. The Web browser.
As time passed, from 1993 to 2005, new and better technologies were incorporated in that “nice graphical browser which displays GIFs and texts in printable fonts”. You got all sorts of improvements on the browser side – Javascript, Java applets, server-side includes, later XML and all the many acronyms that designate a trendy and fashionable technology of the year. But on the server side, things improved as well. The whole industry started to create platforms and frameworks that were designed from scratch to produce Web pages easily. The notion of “web-enabled applications” or “web services” evolved slowly, to mean mostly that you either do it on the Web, or you don’t need to bother. All attempts to create Internet-based businesses which were not Web-based (or Web-incompatible) have so far utterly failed. Remember how Microsoft made a 180º turn when Windows 95 came out – starting as an anti-Internet company, Microsoft soon became one of the leading builders of the “Web revolution”.
But now we have – finally! – a new technology to replace the 2D browser-based Web: virtual worlds! This could be the new paradigm shift that will bury the rectangle thingies on our cluttered desktop. However, the key issue is that things like Second Life should not fight the 2D paradigm of the Web, but assimilate it, by incorporating its protocols into the virtual world itself. And this seems precisely to be the route Linden Lab has taken. 3D content uses a Linden Lab technology; but integration with the myriad applications, systems and servers “out there” in the Internet, will use the “common” protocol that they all are happy to “speak”: HTML over HTTP.
On my earlier posts, I imagined that 3D virtual shops would appear in Second Life’s virtual world, and that people would pick clothes and items that “look like” the real items, and eventually buy them in-world, to get them delivered off-world, by postal mail. That’s the model for c-Commerce (cybercommerce). My only question was, how would this work, in terms of technology?
Now the answer is simple: take the existing framework – web-based applications. But have Second Life talk to those applications directly.
Imagine how SLamazon could work. On the 2D WWW, you go to www.amazon.com, and either you go to a page with a certain category, or you do a “find” from a search box. You see a picture of a book or of a CD. In the first case, you may have an excerpt of the first chapters to read online; in the second case, you may have a sound bite to download. Finally, you enter another page, write down your credit card number, and the item gets delivered to your home.
SLamazon will use exactly the same backend servers to deal with the logistics, but the interface will be different. You have a plot which looks like any “real” bookshop. You can either visit a certain room (corresponding to a category) or eventually have a search engine which will teleport you to the right shelf. On each shelf you see digital analogues of books – like the ones you can pick up at the Book Expo for the forthcoming SL launch of Cory Doctorow’s latest novel. You can open these books, zoom on them, and read the first chapters. Or, if you’re at the CD room, you see the small CDs that you can attack to yourself and they’ll happily play a 10-second clip. Now you can pay the object, and automatically, SLamazon’s back-end servers dealing with the logistics will be able to deliver your book or CD to your home.
Of course, this also means that SLamazon will auto-rez shelves according to statistics from their data-mining applications. They will know which shelf should have the bestsellers or the latest published books. The book contents (the chapter excerpts) are actually HTML which comes from their web site. Probably the music in the shop will come from a streamer, playing the most wanted song on that week’s hit list. And it will also mean that you’ll probably meet one or other “bookshop attendant” – an SLamazon employee, working in shifts to staff their SL shop – that will help you out and pick related choices for you. And, best of all, you’ll be able to shop with your friends, who will also use “word of mouth” to advise you on what should be good choices.
Now all this can happen. It’s not wishful thinking. It’s Second Life’s “3D browser”, web-enabled to talk to Amazon’s back-end servers. They will be able to provide all content that is currently 2D and limited to a Web page automatically into a 3D world. The best part of it, of course, is that if you plan it well, you can support both the “legacy” 2D Web as well as the new 3D virtual world environment.
Shopping is a possibility, but what about other areas? Well, imagine that Warner Brothers sets up a “virtual movie theatre” – you could watch trailers, but you could also buy tickets from in-world. Or imagine your favourite airline selling you tickets. Or your homebanking system working in-world – but this time, your bank’s virtual ATMs will look like real ATMs, and not be a pretty web page, although they would use exactly the same back-end servers to process all the data.
The key point here is that you will not need to change the back-end servers – where all the “business logic” is. You will not need to replace databases, security systems, and all the needed services and systems to mantain your “web front”. As a matter of fact, if well done, you may even be able to have SL talk directly to your “web front”. Just the interface and the interactions will be very different.
So, I’m not really so excited of being able to open up a Web browser to be able to make a choice at Amazon or read my mail online. Instead, I’m excited about the possibility of entering a 3D representation of a bookshop, which looks and feels like a bookshop, but that in reality is sending HTTP requests to and from the back-end servers of Amazon.
Fully understanding this paradigm is what will take more time.
I have talked about these issues to many skeptics in SL. Interestingly enough, many are technical-savvy, and come from the computer and IT industry. They see Second Life as a “thing in itself”. Their major argument is mostly “why would someone launch an incredibly heavy application to do their shopping online, when they can use a Web browser much more easily?” And, of course, the rest of the conversation usually degenerates in issues like if the implementation of the Gecko renderer will be able to clear cookies, or block pop-ups, or how you can avoid your IP to be known. Just take a look at the transaction logs from the Town Hall meeting with James Linden. I mean, people were worried if they could use ActiveX objects inside the SL browser! (as someone who never used an ActiveX-compatible browser in my entire life, I naturally couldn’t care less)
As usually, the point is so often missed by my fellow residents. They forget the recent history: in 1993, we did not have 3D virtual worlds with the complexity of Second Life running on personal desktop computers, but we had “incredibly heavy applications” that took a huge amount of resources to run, just to view a few GIF images and some nicely rendered text on a grey background. And the exact issues were raised back then – who would use such a cumbersome interface, when text-based browsing did the job so well, even back then?
Well, let’s look at history and learn a bit. Paradigm shifts are never easy to understand, even by people with a technological background who are supposed to be riding the waves of the state-of-the-art innovations.
I certainly look forward to a Second Life WWW experience. The more I think about it, the more uses I find for it. Some, of course, are based on 3D replacements for the current 2D WWW experience, and this is the first step when one technology “assimilates” another. But I’m amazed at how many things will be possible only on 3D. Being “backwards compatible” with the “legacy WWW” and bringing brave new uses for a brand new technology is what I hope to be the success of Second Life – or whatever will come next.
