I’ll be giving a presentation on CouchApps at OSCON if you want to learn more about CouchApps, JavaScript, and HTML5. This presentation will be a part of the JavaScript and HTML5 track. You can save 20% on registration with the code OS11RAD. I’ll also be presenting a tutorial on Learning CouchDB at OSCON Data.

You can also check out my books Writing and Querying MapReduce Views in CouchDB and Scaling CouchDB if you’re interested in learning more about CouchDB in general.

The Web still trumps the Mobile Web. If you’re making a web app, don’t let “mobile first” lead you astray.

Luke’s original premise is not wrong, but I think many web developers have interpreted “mobile first” as “mobile only”—often intentionally, sometimes by accident. As Chris pointed out, it’s easy to let “mobile first” lead you astray. My response to Chris was that the goal should be One Web, even if “mobile first”. “Mobile only” should rarely, if ever, be the goal. The concept of One Web is described in the W3C’s Mobile Web Best Practices 1.0 Basic Guidelines. From the original document:

The recommendations in this document are intended to improve the experience of the Web on mobile devices. While the recommendations are not specifically addressed at the desktop browsing experience, it must be understood that they are made in the context of wishing to work towards “One Web”.

As discussed in the Scope document [Scope], One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts (see 5.1.1 Thematic Consistency of Resource Identified by a URI).

Let’s not let the web fragment into a “mobile web”, a “desktop web”, and a “whatever comes next” web—there’s no reason for this. The underlying technology is designed to allow for One Web, as Ben Ramsey added:

@BradleyHolt @shiflett This is why we have content types, accept headers, user agent strings, and content negotiation.

If you’re considering taking a mobile first approach, please consider taking the One Web approach instead. Your main focus can be on mobile to start, but at least deliver something of value that is not dependent on the client being a mobile device. As Ben suggested, use content types, accept headers, user agent strings, and content negotiation to deliver the best experience based on your user’s device or browser.

strategy != tactics. Having a website was strategic in 1995, seo was strategic in 2005, mobile is strategic today.

Chris is likely talking about startups here (since startups are the focus of much of his writing). If you’re not sure what the difference is between a strategy and tactics, Seth Godin has a good explanation:

Here’s the obligatory January skiing analogy: Carving your turns better is a tactic. Choosing the right ski area in the first place is a strategy. Everyone skis better in Utah, it turns out.

Based on the pattern that Chris outlines, by 2015 mobile may transform from a strategy to a tactic. By 2015 websites, SEO, mobile, and likely even social will all be tactics that startups can employ—but not strategies themselves. This got me thinking, what will be the major new and successful strategy for startups in 2015?

My bet is that, by 2015, radical decentralization and user ownership of his or her own data will be used by startups to gain a strategic advantage over incumbents. To a certain extent, this has already started. The distributed social networking service DIASPORA* is attempting to gain market share from the likes of Facebook by offering users “choice”, “ownership”, and “simplicity”. I don’t know if DIASPORA* will ultimately succeed (they should focus on creating a better web, not just a better Facebook), but they got a lot of attention and traction with their attempt to create a decentralized social network. This demonstrates at least some interest in their stated ideals of freedom, user ownership of his or her own data, privacy, and decentralization.

By 2015 I think that these concepts will evolve and we will see implementations that are much more interesting and compelling than what we see today. These implementations (in aggregate) will have a broader scope than just social networking. Users of centralized services will be more savvy when it comes to issues such as privacy (no, privacy is not dead). Everyone will have the computing capacity needed to run their own part of a truly decentralized system (arguably this is true today). The technology and tools needed to create radically decentralized systems will be accessible to developers (arguably this is also true today). The combination of user demand for more control, more ubiquitous computing (via the evolution of mobile computing), availability of decentralized software platforms (e.g. CouchDB), and startups looking for a strategic advantage over incumbents will lead these new startups to focus on creating radically decentralized systems.

Atom Syndication Format

Most of VPR’s web content is currently stored in a proprietary content management system (CMS). The first step was publishing the needed content from the CMS out into an open format. VPR’s Dan Allen published from the CMS Atom feeds of the various content we would need for the new homepage.

PHP and Zend Framework

Once we had the needed Atom feeds, we created a Zend Framework web application to import these feeds. Components such as Zend_Feed_Reader made the job easier. The weather data comes from the National Oceanic and Atmospheric Administration’s (NOAA) National Weather Service’s National Digital Forecast Database XML/REST Service. The market data comes from the Google Finance API.

CouchDB

All of the data (except for weather, which is pulled directly with a bit of caching) is stored in CouchDB. Since we’re storing documents with varying metadata (i.e. Atom entries) choosing a document-oriented database made a lot of sense. CouchDB’s map/reduce views make for very efficient queries. Its RESTful HTTP API provides a lot of options for scaling and caching. We’re caching documents within the Zend Framework application and conditionally requesting these documents from CouchDB with ETags when a cache is available. The current cache is simply file-based but we’re considering using Memcached for even better performance. On a related note, the homepage itself also supports conditional HTTP requests.

Apache and nginx

We had the pleasure of working with another great Vermont company, ClearBearing, on this project. ClearBearing handles the infrastructure layer for VPR.net. The current website was (and still is) served up by Apache. ClearBearing already had nginx in place as a reverse proxy to handle caching. Since we weren’t replacing the entire CMS we needed a way for the existing CMS and this new application to coexist. We decided to host the new application separately (still administered by ClearBearing) and reverse proxy requests for certain URIs (primarily the homepage) to the new application. This provides a clean separation between the new application and the existing CMS while still allowing for them to be hosted on the same domain from an end-user perspective.

Licensing

You’ll notice that all of the standards used are open standards and all of the technologies used are free and open source software. Additionally, all of the code we have written for VPR is licensed to them under the permissive New BSD License. This means that VPR is free to use this code however they want, study and modify the code, and redistribute the code as-is or modified. They can do all of this without paying additional licensing fees.

Design

While this post is primarily about the technology behind VPR’s new homepage, I should mention that Found Line’s Jason Pelletier designed the new homepage and implemented all of its HTML and CSS. We worked closely with Jonathan Butler and John Van Hoesen, Vice President for News & Programming, to make sure the new design meets the needs of website visitors and the organization.

Next Steps

The launch of this new homepage was just one iteration with many more to come. As Jonathan Butler mentioned in his blog post, VPR has plans to further improve online services for their listeners. Look for a redesigned VPR Classical page soon. There are also plans for better mobile access to VPR and VPR Classical programming. Fortunately much of the work that has been done can be leveraged to create additional online services for VPR’s listeners.

A special thanks for the support of VPR’s listeners—you made this new homepage possible! If you have questions, comments, complaints, or suggestions about the new homepage then please contact VPR directly with your feedback (although you’re welcome to comment here as well).

Real web designers write code. Always have, always will. #aea

This sparked many conversations including these two tweets from Chris Shiflett:

According to @zeldman, real web designers write code. (I think he means HTML and CSS, not PHP, Perl, and Python.) What do you think?

I’ve now asked, separately, whether developers and designers should know HTML and CSS. In both cases, most think they should. Interesting.

To which I responded (brackets added):

@shiflett IMHO, the demarcation between web developers and web designers should be POSH [Plain Old Semantic HTML]. That’s what both need to know.

I have a pretty strong opinion about this. You could say that I have the luxury of working with an excellent designer who implements all of his own CSS—even tackling much of the JavaScript coding on websites we build. To be clear: he is a designer, not a developer—working in both print (which is more technical than you might think) and web.

The typical process is summarized well in Marco Tabini’s PHP Advent 2009 post on CSS and Other People:

From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of HTML and CSS that will render properly on browsers that are often at complete odds with one another.

In my opinion, that process is broken. Why is it assumed that because HTML and CSS are “code” it should be a developer’s job to implement these? Any decent designer is already familiar with the concept of separating presentation and content with style sheets (which are supported in Adobe InDesign, QuarkXPress, and even PageMaker and Microsoft Word). Is learning HTML and CSS, both declarative languages, considered too hard for designers?

Let’s take a look at comps and the dreaded “s” word—slicing. As Marco pointed out, trying to “slice” a comp into HTML and CSS is “sometimes impossible” and “always challenging.” If a designer is only providing a comp, and not the HTML and CSS, it is very likely that the designer does not have a solid understanding of things like progressive enhancement, browser compatibility, and even what is possible on the web.

The use of a comp generally assumes that design is purely visual and that all representations of the web page should look exactly like the comp. How should the content be presented to screen readers, to mobile devices, and in print? Sure, you could provide comps for each of these scenarios but this is not scalable and you quickly risk violating the “One Web” concept. Thinking of a web page through the lens of only one specific visual representation of that page is very limiting.

Do you agree that the typical process is broken? If so, what are the barriers to fixing this process? Do we need better trained web designers? Do organizations need to be educated on how to better structure their web teams? This problem will eventually self-correct. My prediction is that teams with web designers that know HTML and CSS will create better websites and web applications and be more successful than teams using the old process.

• 8.9 inch 1024×600 LCD
• 1 GB of RAM
• Linux or Windows XP
• 20 GB SSD (Linux version) or 12 GB SSD (Windows XP version)
• 900 MHz Intel Celeron CPU
• 1.3 megapixel webcam
• measures 225 x 165 x 35 mm (8.86 x 6.50 x 1.4 in) (WxDxH)
• weighs about 1 kg (2.2 pounds)

Unfortunately the PC 900 isn’t available in the US yet. Rumor is that it will have a $499 price tag when it’s available here.

I find it interesting that the Eee PC is helping to push Linux on the desktop (well, on the ultra-portable) through the installed Xandros distribution. However, I would probably install eeeXubuntu if I were to get an Eee PC. I would have no interest in running Windows XP on the Eee PC.