Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

GWT OAuth and LinkedIn APIs

LinkedIn Logo When I worked at LinkedIn last year, I received a lot of inquiries from friends and developers about LinkedIn's APIs. After a while, I started sending the following canned response:

For API access to build LinkedIn features into your application, fill out the following form:

   http://www.linkedin.com/static?key=developers_apis

For requests to build an application, go to:

   http://www.linkedin.com/static?key=developers_opensocial

I talked with the API team and they did say they look at every request that's sent via these forms. They don't respond to all of them b/c they know that many people would be angry if they told them "no", so they'd rather not have that headache.

Yesterday, I was pumped to see that they've finally decided to open up their API to Developers.

Starting today, developers worldwide can integrate LinkedIn into their business applications and Web sites. Developer.linkedin.com is now live and open for business.

First of all, congratulations to the API team on finally making this happen! I know it's no small feat. Secondly, it's great to see them using Jive SBS for their API documentation and developer community. My current client uses this to facilitate development and I love how it integrates a wiki, JIRA, FishEye, Crucible and Bamboo into one central jumping off point.

I've always been a fan of LinkedIn, ever since I joined way back in May 2003. However, I've longed for a way to access my data. LinkedIn Widgets are nice, but there's something to be said for the full power of an API. Last night, I sat down for a couple hours and enhanced my Implementing OAuth with GWT example to support LinkedIn's API.

I'm happy to report my experiment was a success and you can download GWT OAuth 1.2 or view it online. For now, I'm simply authenticating with OAuth and accessing the Profile API.

OAuth with GWT

In the process, I learned a couple things:

// For LinkedIn's OAuth API, convert request parameters to an AuthorizationHeader
if (httpServletRequest.getRequestURL().toString().contains("linkedin-api")) {
    String[] parameters = httpServletRequest.getQueryString().split("&");
    StringBuilder sb = new StringBuilder("OAuth realm=\"http://api.linkedin.com/\",");
    for (int i = 0; i < parameters.length; i++) {
        sb.append(parameters[i]);
        if (i < parameters.length - 1) {
            sb.append(",");
        }
    }

    Header authorization = new Header("Authorization", sb.toString());
    httpMethodProxyRequest.setRequestHeader(authorization);
}

You might recall that my previous example had issues authenticating with Google, but worked well with Twitter. LinkedIn's authentication seems to work flawlessly. This leads me to believe that Twitter and LinkedIn have a much more mature OAuth implementation than Google.

Related OAuth News: Apache Roller 5 will be shipping with OAuth support. See Dave Johnson's What's New in Roller 5 presentation for more information.

Update December 6, 2009: I modified the gwt-oauth project to use GWT 1.7.1 and changed to the Maven GWT Plugin from Codehaus. Download GWT OAuth 1.3 or view it online.

Posted in The Web at Nov 24 2009, 03:46:05 PM MST 7 Comments

User Interface Schema Definitions

On my current project, we're developing a "designer" tool that allows users to build forms in their browser. These forms are displayed in various channels (e.g. web, mobile, sms) to capture data and make decisions based on user input.

When I joined the project, it was in a proof-of-concept phase and the form definitions created where serialized as XML (using JAXB) with element names that seemed logical. Now that we're moving the PoC to production mode, we're thinking it might be better to change our form definitions to leverage something that's more "industry standard". If nothing else, it'll help with marketing. ;-)

This week, I was tasked with doing research on "existing user interface schema definitions". I'm writing this post to see if there's any major specifications I'm missing. I plan on providing my recommendation to my team on Monday. Here's what I've found so far:

  • User Interface Markup Language (UIML): At 120 pages, the 4.0 spec seems very detailed. I'm not sure we'd use all of it, but it's interesting how the spec allows you to describe the initial tree structure (<structure>) and to dynamically modify its structure (<restructure>). It also has the notion of templates, which mirrors a similar concept we have in our application. Furthermore, it has VoiceXML support, which could be useful if we use call centers as a channel.
  • USer Interface eXtensible Markup Language (UsiXML): I admit that I haven't read much of this specification -- mostly because the UIML spec seemed to cover most of what we needed (especially since we're most interested in describing forms). As far as a I can tell, the major difference between UsiXML is its being submitted to the W3C for standardization (according to Wikipedia), while UIML is being standardized by OASIS. Beyond that, I find it strange that UIML's spec is 120 pages and UsiXML is 121. Neither project seems to have any activity this year.
  • Numerous others: including AAIML, AUIML, XIML, XUL, XAML and XForms. XForms seems like it may be the most logical if we're only interested in form layout and describing elements within them.

If all we're interested in is an XSD to define our forms, the most appealing specs have them: UIML, UsiXML and XForms. If activity is any sort of motivator for adoption, it's interesting to note that XForms 1.1 was submitted as a W3C recommendation a couple weeks ago (October 20, 2009).

If you've developed some sort of "form designer" tool that renders to multiple channels, I'd love to hear about your experience. Did you use some sort of industry standard to define your form elements, layout, etc. or did you come up with your own?

Posted in The Web at Nov 06 2009, 03:18:25 PM MST 4 Comments

Ajax: The State of the Art with Dion and Ben

This morning, I added Dion and Ben's talk titled Ajax: The State of the Art. Below are my notes from the event.

Ajax started out as a bunch of hacks. It showed that we could take our web interfaces and do a lot more with them. A hack isn't necessarily a bad thing. Often, they turn into something much more elegant over time. The new browsers have many amazing capabilities that we haven't taken advantage of yet. We've seen discussions on Ajax go from how to do XHR to frameworks and how rich and mature they are. Dojo is great for Enterprise Development (packing system, namespaces). jQuery is well-suited for lightweight developers (PHP). Prototype is fantastic for people who do a lot of JavaScript development and take it very seriously.

Today's Ajax landscape is mature, really rich, and really exciting. Today, Dion and Ben are going to talk about technologies they're really excited about for the future.

Canvas
The building blocks of the web are text, boxes and images. With canvas, it really makes a lot more things possible. You can do bitmap rendering and image manipulation. They're showing a slide with Doom and Mario Kart running. Canvas 3D does true 3D rendering. Firefox and Opera have done prototypes of this. Can you do canvas-type things today in a browser? Yes, if you use Flash or Curl. Dion and Ben are excited about canvas over plugins for the following reasons:

  • No start-up delay
  • Available on mobile devices today
  • Rendering fidelity with browser (especially important for typography)
  • No bridges necessary (no marshalling/unmarshalling)
  • Not a plug-in

The <canvas> tag originally came from Apple's Dashboard. Dashboard's programming model was in HTML and JavaScript. Dashboard is using WebKit under the covers. Today, canvas support exists in every major browser except for IE. The good news is there are Flash and Silverlight bridges to add support to IE. There's also an ActiveX component that wraps the Firefox implementation and allows it to run in IE.

SVG
Dion and Ben aren't that excited about SVG because it's such a huge spec. We've been struggling with the HTML standard for the last 10 years and the thought of another huge spec for the next 10 years isn't that appealing.

Fast JavaScript
Almost all major browsers have a Fast JavaScript implementation. Chrome has V8, Safari has SquirrelFish Extreme, Firefox has TraceMonkey and Opera has Carakan. This is exciting because of industry trends and how companies are trying to reduce computation cycles in data centers. The more computing that can be put on the client, the better. IE doesn't have anything, but Dion and Ben believe they are working on something.

Web Workers
Interface latency is awful for applications. Jakob Nielsen once said:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously. 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay.

Anything that takes longer than a tenth of a second should be pushed to a background thread. Unfortunately, there are no threads in the web. Maybe we can add threads to JavaScript? Brendan Eich has said that "Threads suck" and there's very little chance for threads getting into JavaScript. Gears brought Worker Pools and this is going into HTML 5 as Web Workers. You could also use Java applets to do this. With the latest Java Plugin, many of applets' long-standing issues have been solved.

Desktop Integration
The ability to build desktop apps as web apps is very exciting. There's a few technologies that demonstrate this: Fluid, Mozilla Prism, Adobe AIR, Appcelerator Titanium and Gears. The Palm Pre demonstrates the logical extension of this. The Palm Pre uses the web stack as its developer SDK. It's very cool that web developers don't have to learn anything new to become a Palm developer. Desktop integration is exciting especially if we can access desktop applications like email and address book.

The Ajax frameworks that are out there have done a lot to make web development simpler. However, there's still a lot of pain with CSS and cross-browser issues. What if you took canvas and combined it with a sophisticated grid-based layout in JavaScript?

There's a lot of platforms out there: Microsoft Silverlight, Adobe Flash, Apple Cocoa and Sun's JavaFX. The web often isn't considered a platform. Dion and Ben believe there should be an Open Web Platform. The problem right now is there is no central location to find out how to get stuff done. You have to search and find resources from many different locations. Mozilla is putting it's resources into creating an Open Web Platform. This site will consist of 4 different areas:

  • Home
  • Documentation (for different frameworks, browsers, quirks)
  • Dashboard (state of the open web)
  • Roadmap (what's going on)

This is not just Mozilla, it's very much a community effort. This is something that Ben and Dion have been working on. But there's something else they've been working on too. They've been talking about all these cool things, but what about an interesting application to test all these technologies?

Bespin
As they looked at code editors, most of them provide awful user experiences. Bespin is the Editor of Your Dreams and contains the following features:

  • Accessible from anywhere - any device in any location
  • Simple to use, like Textmate (not heavyweight like Eclipse) - an editor, not an IDE
  • Wicked Fast - performance, performance, performance
  • Rock-solid real-time collaboration, like SubEthaEdit - it just works
  • Integrated command-line, like vi - Fun like Quicksilver, social like Ubiquity
  • "Self-hosted" environment, like Emacs - For extreme extensibility, but with JavaScript!
Dion and Ben are showed a screen shot of Bespin and now they're doing a demo. The core editor has what you'd expect with syntax highlighting and line numbers. Canvas doesn't have text-selection by default, so they had to write it from scratch. The command line allows you to get help, run core command and also to subscribe to commands that others write. You can change your keybindings to emacs or vi as well as many other settings. Much of Bespin is event-driven, so you can easily plugin new behavior for different events.

For viewing files, they couldn't bring themselves to use a tree. Instead, they developed a file-browsing interface that looks very much like Apple's Finder. Personally, I like Finder, but wish it had Windows Explorer's path bar that allows you to simply type in the path without mouse clicks. Back to the command line. They've done a lot to make things more discoverable so users can easily find the power of the editor.

Bespin could be used to engage developers more with open source projects. Checking out projects, modifying code and creating patches can be a real pain. Bespin could be used to interface with open source projects in the cloud. You could login, modify code and easily patch/build with the click of a button. One other thing they want to do is to have the server do code-analysis as you're developing.

Is it OK to love a software tool? You must love your software tools. What we do as Software Developers is one of the most difficult jobs on the planet. Programmers, like poets, start with a blank slate and create something from nothing. If you don't love your tools, you'll start resenting what you do. If you don't love your tools, it shows in your work. -- Dave Thomas at RubyConf08

Thunderhead
A GUI Toolkit written with canvas and JavaScript. Allows you to do layouts with very little thought. It's a lab experiment that's in progress, stay tuned for more information.

All users care about is the user interface. Dion and Ben believe there's a key to creating compelling user experiences. It all has to do with managing expectations. It's not that different from how you manage relationships in your life. Expectations for movies and games have changes drastically over the years. What used to be the web (animated gifs and awful web pages) has also changed drastically (video of Apple's online store). What was cool with MapQuest got changed drastically with Google Maps. What we have today isn't the end of the game - expectations will continue to change. However, users have different expectations for software.

Alan Cooper has done some interesting work in this area. The software designer needs to focus in on a user's goals. There are basic things you can apply to all users, for instance "sex sells". An example of this is Delicious Library. This application allows you to keep track of things in your home such as books, movies, music and games. They made $500K in 3 months and made $54K the first day, with no advertising.

The quality of any software is determined by the interaction. If the interaction isn't good, it will poison the entire experience. Donald Norman has a good quote: "Attractive things work better". In society, this is often called "Dress for Success".

The Open Web is hear to stay because it has:

  • An Easy Programming Model
  • Easy Remoting
  • Extensive Customization Vectors (e.g. GreaseMonkey)
  • Easy Deployment
  • Great Widgets
  • Great Visual Effects
  • Great Mobile Story
  • Desktop Integration
  • State-of-the-Art Plug-ins

Bespin is a tech preview that they hope to release next week. Thunderhead will be released at the same time.

Conclusion
This was a great talk and easily the most inspiring of the conference. Dion and Ben always do a great job and the sexiness of their presentation made it all the more appealing.

Posted in The Web at Feb 05 2009, 11:03:10 AM MST 4 Comments

The State of the Web 2009

This afternoon, I attended The State of the Web 2009 at Web Directions North. Below are my notes from this session.

This panel has quite the list of superstars:

John is moderating this session and is starting by asking each panelist to speak about what they believe the state of the web is.

Chris Wilson
The future of the web may be as ubiquitous as electricity. Chris has a desktop, two laptops (one 10" NetBook, one is a 13" MacBook) and an iPhone. There's a lot of difference between these devices, especially when it comes to screen size. Chris uses a number of different browsers throughout the day. The web isn't just one browser, it isn't just one platform. He's showing a slide with a browser market share graph from http://www.netapplications.com.

Many different browsers are a reality. Many different devices are a reality. Web builders need to learn to write scalable applications that run across multiple browsers, devices and environments. They need to use progressive functionality and learn the tools they have in CSS and HTML. Semantic structuring helps.

Developers need to learn to live with multiple browsers. Cross-browser interoperability will get better, but it's likely to be an issue forever. Test suites with new specifications are helping. Developers should build for browsers of today and tomorrow.

You should build the applications you want to build and then figure out how how to make them degrade gracefully on the web.

Lars Erik Bolstad
Opera Software has 600 employees in 10 countries. They've been developing Opera and other browsers since 1995. The bulk of what Opera does is based on commercial browser deliveries to OEMs around the world.

Devices, platforms and networks: they come in all shapes and sizes. Only one thing unifies them: The Web. The browser is becoming more and more important on these devices. Users are not satisfied with WAP-based content anymore, they want the same content no matter which device they're using.

Opera Mini does its processing on the server-side. This allows Opera to gather statistics. These stats show that users around the world hit the same top sites on their mobile devices as they do on their desktops. It's a one-to-one match. Opera is seeing tremendous growth in the usage of Opera Mini, both in developed countries and emerging markets.

The point: don't just develop for desktop browsers. The mobile market seems to be growing much faster. The problem is actually more in the hands of browser developers since they have to satisfy the user's desire to see the same content on mobile vs. desktop.

Opera is focusing on advancing core browser technology in three areas:

  • Web standards: CSS (webfonts, backgrounds/borders, transitions, transforms), HTML 5 (video/audio, persistent storage, drag and drop) and W3C Geolocation API and "Mobile DOM" API (access to camera, address book, calendars).
  • Performance: VEGA (vector graphics-based rendering, hardware acceleration) and CARAKAN (new JavaScript engine, native compilation). For more details, see http://my.opera.com/core.
  • Web applications: Standalone web apps, RIAs, Widgets. Gears support and Developer Tools.

Dan Connolly
The web is kinda important these days. It's a big deal. Make a mistake and 300 million dollars go away (see end of last entry about United news). One of the beauties of the web is you can easily participate as an individual. You can report bugs, write articles and be a part of many web standards groups. Most of the other systems in the world don't provide this kind of access.

Dan has been under a rock for the last 5 years working on Semantic Web stuff. Now that he's back in the game, it's incredible how much stuff is going on. He's glad there's JavaScript frameworks so he doesn't have to learn everything. The default security policies in browsers are a little rickety at this point. They allow you to download and run JavaScript from virtually any site. Caja might help to solve this. Dan believes that security will become more important and stricter to protect web users.

Scott Fegette
Scott is a Product Manager in the Web Group of Adobe. At the beginning of each year, they do heavy user research. Adobe wants people that develop content for the web to be as expressive as possible. Scott is going to give us a peak into the conversations he's had with the web community.

One of the biggest topics on people's minds is The Economy, but it's not negative as you might think. Small web designers are actually getting more business in the downturn, likely because companies are polishing their presence on the web. People are working much more distributed these days. There's a few areas that Adobe generally asks about: CSS, JavaScript, HTML (both statically and dynamically).

Frameworks are becoming more important to developers, as well as with clients. They've even seen some clients demand certain frameworks. Two years ago, when Adobe talked to small design shops and agencies, most web sites were built statically. Now they're developing with frameworks like WordPress. Out of 60 folks they talked to, only 2 were using static systems and not CMSes.

In the JavaScript frameworks arena, jQuery is the dominant leader. Shops are starting to use CSS frameworks as well. The only one Scott mentioned was Reset. Design is becoming a technical discipline and Adobe is calling this Stateful Design. WYSIWIG is definitely dying and designers aren't developing with visual tools.

The kind of projects that people are working on has changed a lot. Many shops are being asked to do work on mobile development. The iPhone has done wonders for the industry in raising the awareness of what a mobile device can do.

The other big investments for Adobe is RIAs and AIR. Ajax has matured enough that it can now compete with proprietary plugins like Flash. The reason for AIR is to allow web developers to use their skills to develop desktop applications. Flash and Flex are often overkill for browser-based applications, but they do often handle video and audio better than Ajax applications.

Mike (TM) Smith
Mike is also known as the "W3C HTML jackass". Mike thinks the state of the web is that it's a mess in a lot of ways. If you don't believe him, ask Doug Crockford. Most of this stuff is going to remain a mess for the next 20 years, unless another genius like Tim Berners-Lee comes along and invents something new. However, the good part about it being a mess is that we all have jobs.

One of the biggest things they're trying to do with HTML 5 is not breaking backward compatibility. Other working groups at the W3C don't share this philosophy, hence the reason they don't have browser vendors participating. Many of the ideas for HTML 5 game from Gears and Ajax Framework developers like John Resig. All this will make things less messy, especially with the help of browser vendors.

Developers like the ubiquitous web and are pushing the mobile web. Mike thinks everyone just needs to get a life (big applause). For mobile, SVG has already been a big success. You will see significant great things with SVN happen in major browsers by next fall. If you're a web developer, you should spend some time experiment with SVG. It will payoff for you. If it doesn't pay off for you and you see Mike next year at Web Directions North, you can punch him in the face.

Location-aware applications will be big as well. Browser vendors are implementing the Geo Location API. It's implemented in Opera, Firefox, WebKit and Gears. Video on the web will be significant as well. The SVG working group pioneered video support into standards, before HTML 5. Many of the problems they face are related to video codecs. The only way to solve the problems with video on the web is with money and lawyers. Very specifically, there's no royalty-free codec for video. This is nothing that standards bodies can solve. The most promising is that Sun Microsystems is developing an open codec and spending money to make sure they're not infringing on patents.

Not only is the HTML Working Group improving markup in HTML, they're also working on coming up with new APIs that give you access to features. If you have ideas that aren't included in HTML 5, the group is definitely interested in hearing about them.

After each panelist talked, John asked them questions about what's the biggest thing they'd like to see implemented by everyone (open video codec, geo location api were the winners). Mike also did some complaining about XML and how broken it is because there's no failure mechanism. There was some audience banter with Chris about SVG in IE.

Conclusion
This was a very interesting session, especially to hear from the people who are building/supporting the future of the web. I liked Scott's talk on what Adobe's hearing from their users. I also liked hearing Mike (TM)'s opinionated thoughts on XML and his non-marketing approach to most everything related to the web. Lars from Opera had a marketing-ish presentation, but it was nevertheless interesting to hear what Opera's working on. Good stuff.

Posted in The Web at Feb 04 2009, 06:05:38 PM MST 8 Comments

Changes in the Languages of the Web with Dan Connolly

Web Directions North Logo Web Directions is held in Australia and Japan and now the US. A few months ago, they were a bit hesitant about doing it in Denver in the middle of winter. However, they've discovered our best-kept secret: it's beautiful and sunny all week. People are attending this conference from all around the world.

Dan Connolly is the keynote speaker. He's played some very important roles, such as Chairmain of the HTML Working Group during HTML 4. He's also a research scientist at the Computer Science and Artificial Intelligence Laboratory at MIT and a member of the technical staff at the W3C.

Dan's talk is titled Changes in the Languages of the Web and you can view it online at http://www.w3.org/2009/Talks/02wdn/slides.

Web Languages are like languages of the world. Like programming languages, web languages are artificial. Web-native languages are PHP and JavaScript. A Web Language is influenced by natural languages but are artificial. Learning languages is like reading music. With music, most learn from good ol' fashion sheet music. Nowadays, many are learning to read music from Rock Band (the game).

Is there a web language for music? It's not mp3/ogg and it's not Apple's GarageBand. ABC music notation is close and fake-book style cords mostly works. The problem is often these sites and specifications disappear because copyright holders come and scare them away.

Technology deployment rides on the practice of sharing media and culture. Open standards preserve freedom to tinker and supports cultural heritage. Lawrence Lessig at OSCON 2002:

  • Creativity and innovation always builds on the past.
  • The past always tries to control the creativity that builds upon it.
  • Free societies enable the future by limiting this power of the past.
  • Our is less and less a free society.

Lastly, Lawrence asked what have you done about it?

In 1991, some places would fire you for looking at code from the Net. At the time, Dan worked at Convex, who encouraged participation in Free Software. Convex did business with HP; HP used SGML; HTML was SGML (almost). When Dan read about the World Wide Web from Tim Berners-Lee, he had an excuse to look at HTML as part of his day job.

Computer Science students and hackers learn BNF and parse trees. SGML is a little funny looking, but works mostly like BNF. Feedback loop:

  1. Draft a DTD
  2. Run some tests, ask the computer if it matches the test cases
  3. Discover an issue; repeat

While Dan was at Hal in Austin in 1994, and adding HTML support in products, he:

  • Asked other HTML Working Group members to try James Clark's sgmls parser
  • Not many of them were in the habit of building software from source
  • Mark Gaither and Dan installed sgmls as a CGI service
  • Feedback loops works over the Web!

Dan was first the editor and then the chair of the standardization of HTML 4. HTML's standardization timeline:

  • November 1995: HTML 2.0
  • January 1997: HTML 3.2
  • December 1997: HTML 4.0
  • December 199: HTML 4.0.1

Browser marketplace explodes and then stagnates. Early 1990's - lots of little projects. In 1995, Netscape Navigator IPO rewrites the business books. In the late 90's IE takes over Netscape. After HTML, Dan started working on other stuff: Feb 98 (XML 1.0), Jan 99 (Namespaces in XML), Jan 00 (XHTML 1.0), Feb 04 (RDF and OWL), Apr 06 (SPARQL) and Sep 2007 (GRDDL).

W3C fostered many of the technologies of Ajax and Web 2.0:

  • HTML, CSS, DOM, XML from W3C circa 2000
  • JavaScript from Netscape, ECMA in 1995
  • XMLHttpRequest from Microsoft in 1999

W3C's efforts since then lacked clear deployment paths.

XHTML is not the solution to a problem that concerns anybody except the guys who have to write parsers that convert markup into DOM trees. It turns out that XHTML put the validation on the wrong end of the network. It turned out that the market didn't put much value in a document delivery system that could decide to not display the document because there was an unrecognized attribute on an invisible meta tag.
-- Doug Crockford Jan 2008

The web isn't just for computer geeks anymore. From The Future of Information by Ted Nelson in 1997:

The software world currently corresponds to the Pre-Director stage in movie-making (1893-1904). During those years, when short films were already being shown in theaters, the job of making the movie was given to the cameraman - because he knew how to work the equipment.

That is how it is with software today. Today's software designers are those who only understand the technicalities, and not - with rare exceptions - those who understand how to integrate the presentation of ideas to the mind and heart.

The Web facilitates a shift from mass media to participatory culture. Worth watching: An Anthropological Introduction to YouTube by Michael Wesch and the Digital Ethnography Working Group.

The W3C HTML Working Group charted in March 2007 and ended up with hundreds of participants (most prior working groups had 20-30 people). In November 2007, there was an HTML WG meeting at W3C Technical Plenary and was very much an unconference. The HTML 5 Working draft was published in January 2008. Goals for HTML 5:

  • Off-the-shelf parsers and tools for reading web pages like browsers do, including tag soup
  • Modern test materials
  • Standardize successful experiments in the Web Applications platform to balance the attraction of proprietary approaches:
    • <video>, <audio>
    • scripting details, security policies
    • offline storage

HTML 5 co-chairs: Chris Wilson (Microsoft) and Sam Ruby (IBM) with W3C staff support from Mike Smith and Dan Connolly.

Some ideas from the CSS validator roadmap:

  • JavaScript CSS parser
  • Support for CSS 2.1 forward-compatible grammar
  • Integrate test-result data showing browser support

The browser marketplace is moving again.

How about authors? How do they feel about HTML 5? Two days ago, Dan received support from Adobe to work on HTML 5 materials for authors.

Design Principles Last Through Change. From Zeldman on Twitter: Client who saves $5K buying cut-rate non-semantic HTML will later spend $25K on SEO consultant to compensate.

There's still something to the nothing behind XHTML+CSS Web Design. Kudos to whoever designed the Kansas Tax web site (Dan is from Kansas City).

Sharing data in documents is one of the original goals of the WWW. Dan has been investing some of his own time into microformats.

Tantek Çelik in June 2006: "XML formats in the long run are not better than propriety binary formats."

  • XML, both in technology (namespaces...) and as a "technical culture" is too biased towards Tower of Babel outcomes.
  • A few XML formats may survive and converge (RSS, maybe Atom).
  • But for now, XHTML is the only longterm reliable XML format that has more to do with it being based on HTML than it being XML.

And if longevity is not a goal, try JSON - it's yummy.

Microformats are not just technical ideas, but it's something that you can actually use in your life. XSPF - what if media players had used an XHTML dialect a la hMedia. RSS and hAtom - will feed readers grow native support for hAtom? Will calendar subscription clients grow native support for hCalendar? The process and the technology of microformats provide an 80% solution for global scale problems.

The Personal Information Disaster: The bane of my existence is doing things I know the computer could do for me. -- The XML Revolution, Nature Web Matters Oct 1998.

Let's find ways to make it cost-effective record and share knowledge formally, i.e. so that computers can manipulate it. How great would it be if your kid's soccer coach could distribute a schedule that would feed into everyone's calendaring system?

Flickr, Facebook and Twitter demonstrate the attraction of hosted services. Identi.ca supports federation (OpenMicroBlogging). Instant Messaging is much like e-mail used to be, where you couldn't e-mail folks that used a different provider.

Be careful not to delegate too much to machines!

  • A United Airlines near-bankruptcy item from 2002 appeared as 2008 news via Google News
  • Syndication continued up to a Bloomberg news flash.
  • UAL stock cratered from $12 to $3 ($1.14 billion in market cap).
  • The stock recovered within the day to $10 (down $300M in market cap)

Something to keep an eye on - SEC Interactive DATA and XBRL. Three dozen companies, representing more than $1 trillion of market value, have joined the SEC's test group. Have been working on this since 2005.

Conclusion
The balance between proprietary risk/reward and open standards is delicate. Media independence is more important than ever as mobile emerges. When content doesn't match specs, changing browsers is cheap compared to changing all the content, authors. Web technology is deeply intertwingled with social, economic context.

I enjoyed Dan's talk. He's obviously a smart guy and has been involved with the web since before it even existed. More than anything, I like the conference location. It's 1/2 block from my office and has excellent views. I hope to return for The State of the Web 2009 later this afternoon.

Posted in The Web at Feb 04 2009, 11:34:54 AM MST 3 Comments

[OSCON 2008] Even Faster Web Sites by Steve Souders

Steve works at Google on web performance and open source initiatives. To begin his talk, Steve is running YSlow in "autorun" mode. This runs YSlow Performance tests on the top 100 sites according to Alexa. Before Google, Steve was at Yahoo for 7 years. You can download Steve's slides from his site (don't ask me where).

iGoogle with an empty cache: 9% of the time is spent getting the HTML document. The % of time of what a webserver does is a pretty small percentage of the overall picture. If the cache is primed, the time goes up to 17% of the time.

80-90% of the end-user response time is spent on the frontend. Start there.

There's a greater potential of improvement on the frontend. If you improve the backend performance by 50%, chances are the end-user only sees a 5% improvement.

The 14 Rules are encapsulated in the YSlow plugin. At OSCON last year, Yahoo released YSlow. 500,000 downloads since it was released. Following the release of YSlow, Steve wrote High Performance Web Sites.

High Performance Web Sites, Vol 2. The 3 most important rules are:

  • Split the initial payload
  • Load scripts without blocking
  • Don't scatter inline scripts

Why focus on JavaScript? A lot of the top sites use JavaScript. For example, up until a few weeks ago, Facebook served up 1MB of JavaScript, uncompressed. Scripts block parallel downloads and page rendering. To see it in action, go to http://stevesouders.com/cuzillion/?ex=10008.

Any content below a <script> is blocked from rendering - even if it's already cached in the browser. Cuzillion is an open source project that Steve is releasing that allows you to add components to a page and test their performance.

Split your JavaScript between what's needed to render the page and everything else. Load "everything else" after the page is rendered. To do this, you can use Firebug to do it manually, or you can use Doloto from Microsoft to automate the splitting of your files.

MSN.com solves the script blocking problem by using JS DOM to allow for parallel downloading. There's 6 techniques for doing this:

  • XHR Eval (must have same domain as page)
  • XHR Injection (same domain)
  • Script in iFrame (same domain)
  • Script DOM Element (domains can differ)
  • Script Defer (only supported in IE, domains can differ)
  • document.write (not recommended, parallelization only works in IE)

How do these techniques cause "browser busy" indicators? XHR Eval and Injection don't trigger any indicators. You need to choose when you want to show busy indicators. It's good to show them when you want to show your users that something is processing (but not for lazy-loading JavaScript that's not required for load). For the different techniques, most don't ensure order of parsing.

Based on 3 factors, Steve can tell you which technique is best to use. These three factors are 1) the URL of the page and script 2) if you want busy indicators and 3) if you care about order. Steve thinks it would be awesome if web frameworks could support this to write out JavaScript appropriately for the developer's input.

Long executing inline scripts block rendering and downloads. If you know you're going to have scripts like this, you can solve it with a couple workarounds:

  • Initiate execution with setTimeout(>250 for Firefox)
  • Move JavaScript to enternal script with advanced downloading techniques
  • Use defer attribute for IE

In Firefox 2, stylesheets block parallel downloads just like scripts. IE doesn't. However, IE will block when you have a stylesheet followed by an inline script. To solve, it's best to move line scripts above stylesheets or below other resources. use <link>, not @import.

Takeaways: focus on the frontend, run YSlow, focus on JavaScript (split initial payload, load scripts w/o blocking, don't scatter inline scripts).

Three Announcements:

Posted in The Web at Jul 24 2008, 04:23:12 PM MDT 8 Comments

[OSCON 2008] CSS for High Performance JavaScript UI by Gavin Doughtie

Gavin is a front end developer on Google’s Picasa Web Albums and a contributor to the dojo toolkit. The original designer tools for Web 1.0 were the FONT tag, TABLE hacks and spacer gifs. Now we live in the future (shows a picture of the iPhone). Maybe it's time to accept that we're stuck with CSS. "I'm a coder, not a designer" is what happens at OSCON.

There are costs of JavaScript: development, download, parse time and runtime performance. It's extremely powerful and high-level, but it's slow because it's interpreted. Drawing a box with JavaScript in Firefox 3 isn't too difficult. Another way to do the same thing is with CSS. Doing the same thing in CSS is much faster and requires less code. Surrender To Win. You don't have to code it all. You can hand off part of that to your runtime environment (browser).

CSS Fundamentals
You want to how things flow in a page. Browsers were originally designed to render text. They're built to render flowing text. Other important fundamentals include float, positioning, negative margins, relative units, pseudo-selectors. Lastly, you need to know when to use tables. Gavin is now showing an example of using CSS to modify an image so it scales with the browser window. It's pretty simple:

body {
  margin: 0;
  padding: 0;
  height: 100%;
  width: 100%;
  overflow: hidden;
}

img { 
  position: relative;
  width: 100%;
  height: 100%;
}

Relatively Absolutely: "Absolute" in relative to position:relative. If an element has absolute positioning, it will only be positioned relative to it's parent element. To draw a box on an image, it's usually best to calculate the percentage position and sizes in script or on the server. The world's greatest psuedo-selector is :hover. Unfortunately, :hover doesn't work on anything but <a> in IE 6.

With floats, you can "float" elements to the top, right, bottom and left. In Firefox and Safari, you can set a border-radius to draw lines that are curved. Before Firefox 3, these lines where terrible looking.

Tables make a lot of sense when you have a grid layout. Use table-layout:fixed if you don't want table cells to be the width of their contents.

For sizing images and other elements, it's usually best to use em for the height and width and relative measurements. You can then use style.fontSize to resize the images. Using this technique is must faster than using JavaScript to set the height and width on an image.

WebKit, the CSS Wonderland. Gavin loves WebKit. It's on Safari (Windows, OS X and iPhone), Android, GNOME and KDE. With WebKit, you can build expanding lists w/o any coding. To do gradients in WebKit, you use:

background: -webkit-gradient(linear, left top, left bottom, from(#fff), to(#00abeb));
-webkit-border-radius: 0.24em;

To do animation, you can use:

-webkit-transition-property: width, height;
-webkit-transition-duration: 250ms;
-webkit-transition-timing-function: default;

Another thing you can do with WebKit is rotate images (using -webkit-transform: rotate()) and just about anything (divs, forms, etc.). WebKit also supports SVN masks, which means you can open up a hole and view an image through it.

Gecko's pretty cool too. Firefox 3 introduced a new rendering engine based on Cairo. You can do an SVG transform in Firefox 3 to create reflections of elements (divs) in your page.

"With browsers, you cut people off at the knees, but everyone's the same height." -- Alex Russell

IE 6 is not the problem, we're the problem. If you drop support for IE 6, you won't have to worry about coding towards it. It might not be possible if you work for a large company, but if you're small, you should definitely think about it hard.

It's funny to think that IE 6 is the new Netscape 4.

Gavin's slides from this talk will be available at http://xdraw.org/oscon2008.html in the next few days.

Posted in The Web at Jul 24 2008, 03:30:32 PM MDT 1 Comment

The 416

The Few, The Proud, The Pradipta 416

Posted in The Web at Jul 18 2008, 02:10:37 PM MDT 1 Comment

RE: Are people blogging less?

Nice Trail James Strachan asks Are people blogging less? Looking at my archives, I don't see a noticeable decline in the number of entries I'm writing. Granted, I don't blog nearly as much as I did in December 2002.

One interesting thing I've noticed though, is I don't read blogs much anymore. I open NetNewsWire about once a week. However, I don't think it's because of the Twitter effect. I think it's because I work in an office full of people now and I get my social interaction from them, rather than from blogs. I also think it's because I'm more interested in what's going on with LinkedIn and social networking competitors. Most of that news I get from LinkedIn News on the homepage.

If there really is a decline in blogging, it may be because of Twitter, but I think it's something bigger. I think it's folks realizing 1) it's summer and 2) you don't get a whole lot of satisfaction out of blogging - you get satisfaction in life from spending time with family and friends. So quit reading this blog and go read your kids a book or invite your friends to happy hour tomorrow. It's a beautiful time of year and it won't last forever. ;-)

Posted in The Web at Jun 23 2008, 08:54:13 PM MDT 3 Comments

Share on LinkedIn

This is a test to see if I can get the Share on LinkedIn widget working on this site. Click below to invoke.

Share on LinkedIn

Seems to work pretty well. I like how you can select text and it'll automatically populate the summary. You can drag the link above to your toolbar in Safari and Firefox if you want to use it like a favelet.

Now I just need to get one of the designers to create a nifty little "Share on LinkedIn" icon so I can add it to all my entries by default.

Posted in The Web at Jun 05 2008, 10:13:04 PM MDT 4 Comments