deck.js lite: modern HTML presentations

Taking a page out of Don Stewart’s book I’m planning to release a project to the Internet every week or two. Most, if not all, of them will be open source and hosted on Github. I’ll be posting blurbs about them on this blog filed under a new category – Projects. Feel free to follow along or fork away.

Deck.js is a very cool project that provides a set of CSS and JavaScript templates that let you create clean, elegant slideshows using HTML. I’m becoming increasingly attracted to HTML as a general purpose documentation format so seeing like deck.js makes me really happy.

I’m currently using deck.js to put together a presentation for a class I’m taking, but while at it I thought I’d do some reorganization of the deck.js codebase to make things a little easier. The files that you need to include to use deck.js are currently spread out between a number of different folders meaning that as a user it might take you a while to figure out where everything is and what you need to include. So in the spirit of open source I decided to fork the repo on Github and create a ‘lite’ version.

This version (also available on Github under the same license) packs all the files into a single folder, shortens some names and paths and removes some things (tests and SCSS files) that users might not care about. I’ve also updated the introductory presentation to point to the new files so you can use that as a template for making your own slides. I’ve been talking to deck.js’ creator, Caleb Troughton and I plan to keep the ‘lite’ version in sync with the main repo so that you’re always using the latest and greatest.

If there’s anything else you’d like to see in a lite version (or just in deck.js in general) please let me know. I think the best days of the web are just ahead and having web-native slideshows is definitely a step in the right direction.

PS. In case you’re wondering: no, The ByteBaker is not going to become just an announcement board for my projects. However, graduate school is taking up a lot of my time and energy right now. Also I think it’s important that I keep to releasing one project a week. The best I way I can think of keeping to that is by documenting my progress online. Normal programming will resume soon.

Advertisements

Bluebot: a simple HTML template

Taking a page out of Don Stewart’s book I’m planning to release a project to the Internet every week or two. Most, if not all, of them will be open source and hosted on Github. I’ll be posting blurbs about them on this blog filed under a new category – Projects. Feel free to follow along or fork away.

Over the weekend I took a few hours to set up a simple webpage on the Cornell CS department servers. While doing that I realized that I didn’t have a template in store for the occasions where I needed to throw together a page without fiddling for hours. I cobbled together a simple design for my page based on my personal website.

The result is Bluebot: a simple template designed for creating HTML5 webpages. It provides a set of CSS styles and web fonts along with some example HTML for writing clean, decent-looking webpages. It’s designed to be used for standalone pages, i.e. single webpages that are complete in and of themselves. That’s not to say it couldn’t be used or adapted for full websites.

Though the template is mostly black and white, there is a little bit of blue used for the borders and blockquotes, hence the blue. It also makes use of the Droid family of fonts provided via Google Web Fonts, hence the bot.

You can see what Bluebot looks like on the Bluebot project page. You can clone the Git repo or download a tarball from the Github page. I plan on continuing to add styling for the remaining HTML5 elements gradually. Feel free to fork, edit and send me a pull request.

The Web is for Documents: Part II

In my last post I talked about my dilemma regarding webapps: they’re wonderful and they’re letting us do amazing things, but in the effort to become a general-purpose app platform webapps seem to be struggling against the basic document-oriented nature of the web. However, there are some applications that I think are successfully embracing the idea that web is a sequence of connected documents. I mentioned Simplenotes and Dropbox in my last post and they’re both awesome apps that you should check out. However, the document nature of the web has given rise to some new uses that aren’t applications in the conventional sense of the term.

When we hear the term “document” we generally think of something along the lines of a traditional paper document. Perhaps we can blame “word processors” for that. But in this brave new age of Web 2.0 documents aren’t just flat sheets of text. The best demonstration that I’ve seen of this new potential is the HTML5 Slideshow. It’s an HTML web page, but thanks to the the tools of JavaScript and new semantic elements it’s a great presentation too. It probably took a good amount of time and effort to put together and I don’t think you want to put this much of effort into each document. Right now, it’s a great showcase but I’m hoping that eventually there will be tools that make it easier to generate these kind of HTML5 documents with minimal effort, the same way we have great CMSs for building web pages today. There are already HTML presentation tools out there, but right now I think too many of them are trying to hard to clone desktop apps.

Moving on from presentations, another really nice example of innovative documents is the the Google book/website entitled “20 things I learned about browsers and the web”. This is almost certainly not the type of thing you think about when you hear “document” or web-page. Personally I think the pageturn effects are overdoing it a bit, but it presents a large amount of information presented in a very attractive format. I also like that the format they used is quite innovative. It’s not like anything you’d expect to see on a desktop for the simple reason that it’s not a program, it’s a document. Well, that’s not technically true: there’s a significant amount of JavaScript code being executed while you’re viewing it. But would you download and install a program whose sole purpose was to tell you 20 things about browsers and the web? We expect documents to work differently than programs (irrespective of what’s going on in the background): we don’t want to run them or interact with them to perform complex tasks, we just want information. And this book makes access to that information quick, easy and obvious.

Presenting information effectively doesn’t need to have great design and cool animations. In fact, perhaps the easiest way to present information is to get the design elements out of the way and let the content speak for itself. This isn’t a call to ignore design or to consider it as unnecessary frills. Quite the opposite: creating design that doesn’t clutter up the data is a hard job that we’re only just starting to get right. Two services that are leading the pack in this regard are Instapaper and Readability.

Instapaper has the goal of letting you save long form text you find on the web for later reading. The website itself is really simple and behaves mostly as a lightweight bookmarking service; you just save links to things you want to read when you have the time. But it really shines when paired with the iPhone or iPad apps. Instapaper strips websites of all their clutter and presents just the text on a simple background in a good font. It’s goal is simple: putting the focus back on the content and letting you read without distractions. I’ve only used the iPhone app so far, but the iPad app looks really good too. If I had an iPad it would probably be my one of favorites. Instapaper lets you read web-based content without having to be in front of a computer (or even connected).

Next up is Readability. It’s a brand new service who’s mission is similar to Instapaper: make reading easier. But Readability is focused on the web. It’s a browser plugin that will take text-rich web pages and present them in a cleaner, simpler design. There are a number of themes to choose from (I like Inverse myself). There will be Instapaper-like iOS apps soon, but that’s not the real point of Readability. It’s for people who will spend time reading in front of their computers instead of on the move (such as me). I’ve only been using it for a few days, but I’m already hooked. Whenever I see a webpage with a lot of text I want to read, but the design isn’t to my liking I hit the Readability button (or just the backtick key). I get the whole article in a nice serif font on an easy-on-the-eyes dark background as well as a list of things I’ve read recently. You can see that list here. I have some more things to say about Instapaper and Readability, but that deserves to be in a post all by itself.

I think we’re only just seeing a resurgence of the web as a document platform. These are still early days no doubt: creating HTML5 slideshows or flip-page books is not something you can do at the push of a button, but I think we’ll get there. Tools like Instapaper and Readability are helping us take back the web, so to speak. There’s still a lot of to do and I’m pretty sure we haven’t even come close to how far we can push the document-based nature of the Web. I’m certainly looking forward to seeing the new formats and services that get built in the years to come (and maybe build a few myself). While webapps won’t go away, we’ll also gain a lot from the web staying true to its document-based roots.

The Web is for Documents: Part I

I’ve always had something of a love-hate relationship when it comes to webapps. I use a lot of them and by and large I like them. But there was always something about them that seemed just a tad bit … unnatural. I could never quite put my finger on it and over the years as I started to using them more and more I put my uneasiness down to just the newness of the whole thing. By and large, I managed to put it out of my mind or learn to just live with it.

It only came back to me a few weeks ago as I was making plans for an independent study. See, one of the larger gaps in my knowledge of computer technology is networking in general and the Web in particular. I wanted to change that to some extent before I left college and since I had just one semester left I decided to spend my last semester building a webapp of some sort. But when I did that the uneasiness I had felt all along came flooding back. Though I knew that very powerful applications were being built using the current set of Web technologies (mainly HTML, CSS and JavaScript) as I read more and more about web programming something felt wrong. People were writing these huge frameworks and JavaScript libraries in order to build these great programs that ran essentially the same no matter where in the world you were as long as you were running a modern browser. Though it was a great idea and I’m sure lots of hard work had gone into it all, something felt out of place. After exploring the world of JavaScript frameworks and CSS generation tools, I think I’ve stumbled upon the answer.

The thing is, the Web was never built to be a host for dynamic applications. The World Wide Web was (and is) a platform for sharing and displaying documents and it’s only recently that we’ve been trying to hack that document-based framework to enable everything we’re seeing now. Even as the web evolves, the basic standards are still very much true to the Web’s document-based roots. The newest HTML5 specification actually adds a number of semantic elements such as headers, footers, asides and section tags that will help us create better, more meaningful documents. HyperText is ultimately a semantic markup language, no matter how much we try to hack it to be a GUI layout language. JavaScript ultimately manipulates a Document Object Model (the DOM). The inherent document nature of the Web and everything built on it isn’t something that can be ignored and it’s certainly not something that is going away any time soon.

So does this mean that webapps are bad or doomed to failure? Not at all. But it does mean that there are some things that we need to keep in mind as we build and use them. JavaScript does provide a very powerful (and increasingly fast) tool for manipulating our documents in real time and CSS is a good approach for styling and changing presentation (though the language itself could use some work). In order to build webapps that are both useful and feel natural in the context of the web, we should always have the web’s document basis in mind. Webapps that acknowledge and embrace this will have a better time than those that want to only recreate desktop-interfaces on top of HTML5 technologies.

Even today, the most elegant webapps are the ones that have embraced the document idea: Gmail and Simplenote make no pretense to be or mimic desktop apps. The reason that Gmail quickly became more popular than almost any other webmail client out there is that they took a different approach from everyone else: Gmail didn’t try to look or feel like a full desktop app, but it wasn’t just a webpage with links to your messages either. There was a very delicate balance of dynamism and static presentation that makes Gmail so great for the web (as well as no annoying banner ads).

I think the rise of the mobile web and the app store model for mobile devices is helping this new model of webapp become more popular. We’re seeing the rise of cloudtop services — services where the web interface is just one of a group of ways of interacting with the service. Take for example Simplenote and Dropbox. Both have a decent web interface, but also have mobile and desktop apps for the popular platforms and an API allowing others to build inventive applications on top of their services. This means that the webapp doesn’t have to be the be-all and end-all of the user interface. There are many interfaces, each playing to the strengths of their respective platforms.

Of course not all services are going this route. 37signals makes some great web software (or so I’ve heard, I’m not a customer myselft). They’re going all out Web, at least for their Basecamp product. Will it work? Maybe. They claim it’s because they don’t want to have specialized apps for each platform. But the web itself is a platform and the fact that they say that you need a WebKit mobile browser makes it sound like they’re just choosing the web platform instead of native mobile platforms. I personally don’t agree with their direction (and their stated reasons for it), but it will be interesting to see what happens.

I think we’re living in a very exciting time with our technology going in numerous interesting directions. As the idea of cloudtop services becomes more popular, we’re going to see a plethora of native applications that play to the strengths of their native platforms. The ones that are successful on the web will embrace it’s document nature instead of trying to ape desktop apps. And it’s not just apps that we should be looking at, the meaning and scope of documents themselves will change and become better as the Web evolves and its technologies evolves. Stay tuned for part II where I look at some novel types of documents that the web is enabling.