[ SXSW Bios ] #webdead
Wired declared Web 3.0 the age of apps and that the Web was dead and the future is native apps. Insight or naiveté? We’ll discuss the current merits of HTML5, and which companies and technologies will accelerate its adoption among mainstream consumers and create new opportunities for developers. We’ll also discuss the impact this can have on current native application strategies for Windows, Windows Phone 7, Mac, iPhone/iPad, and Android by looking at the impressive work that is being done today with the Web and apps to deliver compelling consumer experiences. But we’ll also address the shortcomings and the reality of HTML and what Web and app designers and developers can and should be doing today. This session is sponsored by Microsoft. Continue reading “HTML5? the web is dead, baby!”
[ SXSW Bios ] #hack5 [ Presentation Files ]
HTML5 is no question the “buzzword du jour” in tech nowadays, but looking past the vernacular cruft one will discover that the HTML5 technology STACK is actually an incredibly powerful & useful framework for apps well beyond the traditional web browser. Massive companies like Google and Hewlett Packard are placing huge bets on the future of “HTML5 App development”. From HP/Palm’s WebOS to be used in their mobility products to Google’s Chrome OS, HTML5 is not simply another buzzword that can be treated as a mere passing trend, but should actually be taken seriously for app development. But what makes up the HTML5 stack and how will it truly be the future of software? What are the benefits & risks associated with using the HTML5 stack? Prove to me it works. All of these questions & demands will be answered & showcased in the presentation including important issues such as: What constitutes the HTML5 stack Benefits of using the HTML5 stack Use a single codebase Rapidly prototype an app targetting multiple devices including: iPhone, iPad, Android Devices, Chrome OS Devices, Mobile Webkit Browsers, Desktop Browsers Target thousands of developers for extensibility & community development See code & install an actual working HTML5 app that works on a number of devices See code best practices in use for tailoring the UI based on the user’s device See code using Phonegap to create native mobile apps See code using Titanium to create native desktop apps Continue reading “one codebase, endless possibilities — real HTML5 hacking”
Future of search from the perspective of semantics. Using the data on the web began with search (literal match), evolved to specific/contextual answers to specific questions, and could move on to asking the web to do something for you more than just answer questions.
Should we drop the term “Semantic Web” and replace it with “Computable Web”?
[ session description ]
- 14 March 2010
Continue reading “beyond algorithms: search and the semantic web”
Forms suck. Creating a style guide for form design is difficult.
- Christopher Schmitt – Heat Vision
- Eric Ellis – Bank of America
- Kimberly Blessing – Comcast Interactive Media
- Sunday, March 15
- web form elements research
- jquery validation
- moz monkey
Continue reading “designing our way through web forms”
At least, tables (can) kill accessibility in web portals.
Accessibility in a portal has always been a challenge. It has to do (initially) with boxes.
Many early portals used quite hideous tables to layout the screen. Hey, a portal is a set of boxes, right? Oracle Portal still enforces a level of table-as-layout. Tables aren’t evil, but as layout devices they make it difficult to control keyboard interaction on a screen. You have to really implement them right to keep them accessible.
But my main problem with tables as a way to arrange a set of boxes is that the boxes (portlets) on a page are not always neat, tabular data in common rows and columns. Tables are for arranging tabular data. That means there are common relationships among the data sets.
A portlet is too complex an interaction to always fit as “tabular data”. The ways I want to navigate a table of numeric data is usually different from the way I want to interact with a portlet or group of portlets. For example, do I have to tab through every portlet (and inside through the inner elements) on the screen in order to get to the one I want (with the keyboard)? Or can I jump through HTML headers like every other well-formed webpage I encounter?
The other problem with tables is styling. Think about how difficult it is to style your own profile at MySpace. Nested tables to the nth degree. Portals are susceptible to this trap as well. Taking a beautiful Photoshop design of a portal interface and then attempting to style unclassed table cells (when tables themselves tend to break certain CSS layout rules–or better yet, when there is inline CSS inside a table definition that you cannot override!) is an exercise in insanity. I mention this because the level of design control I have over my content is usually closely related to the level of accessibility I can ensure in a page.
So the first accessibility challenge for portals is having enough control over the page layout interface to display portlets on a page in a way that is semantic and easy to interact with via a keyboard. The second is having enough freedom to make it look great.