ENTRIES TAGGED "html"
The power of a technology now taken for granted
A friend wanted to show me a great new thing in 1993, this crazy HTML browser called Cello. He knew I was working on hypertext and this seemed like just the thing for it! Sadly, my time in HyperCard and an unfortunate encounter with the HyTime specifications meant that I bounced off of it, because markup couldn’t possibly work.
I was, of course, very very wrong.
Markup with some brilliantly minimal hypertext options was about to launch the World Wide Web. The toolset was approachable, easy to apply to many kinds of information, and laid the foundation for greater things to come.
Flexible dreams for a responsive world
Last week’s Artifact Conference focused on the challenges of designing for multiple devices simultaneously. One frequent suggestions on stage and off was rough sketching, on screen or on paper, but it’s tricky to get there. The problem is easiest to see for designers on the Web, but it applies to a wide range of digital projects.
What does a sketch of a page look like when that page morphs itself to fit differently in different containers? What does a sketch of a site look like when that site may present different content (and different types of content) to different users based on their past encounters with the site? What does a sketch of a program look like when it handles many different kinds of input in many different kinds of circumstances?
One answer – the classic answer for those of us walking around with notebooks full of dot grid paper – is multiple sketches. Breakpoints become critical as “it looks like this when…” becomes a mantra.
At the same time, though, I rarely feel comfortable creating site (or code) details on paper when I know the result will be electronic. I spent way too much time explaining how paper and screens are different to saddened designers to want to inflict that pain on my own projects. My notebooks are largely filled with words, with occasional pictures.
Don't wait for browsers to implement Web Components, try them today
Web Components, the family of new web specifications for reusable and encapsulated widgets, are coming to a browser near you. Thanks to Polymer, a new type of library for the web built on top of Web Components, and Dart, a new structured language and libraries for modern web development, you can build custom HTML elements that encapsulate style, structure, and behavior.
In this article, I’ll show you how to build a simple auto-complete widget as a custom element. As a user types into a field, a list is searched by prefix. The user can keep typing for a more exact match, use up and down to select, or use their mouse.
Defining a powerful toolkit
The rise of the phrase “web platform” over the past few years makes me very happy.
This summer, I’ve seen all kinds of programming approaches as I’ve bounced between the Web, XSLT, Erlang, and XML, with visits to many other environments. As I look through the cool new possibilities for interfaces, for scaling up and down, and for dealing with data, I keep seeing two basic patterns repeating: walking trees (of data or document structure), and handling events.
A language built to support event handling, not strictly a functional programming language but fitting that mold. A deep understanding of markup structures. A home in the browser.
Thursday afternoon at Balisage, O’Neil Delpratt and Michael Kay discussed Interactive XSLT [2.0] in the browser, showing not just the usual transformations but a working engine for a graphical interface. Their earlier XML Prague paper also tells the story and shows more code detail, including a chess game.
Getting past the HTML / XML splits
A few years ago, I stopped talking about XML and starting talking about markup. After a few too many conversations with developers who had found XHTML, web services, and various other things that had proudly branded themselves with the “X,” it was clear from hostile responses that XML’s boom was done.
Many of Wednesday’s Balisage talks wrestled with the challenges XML tools face in a world dominated by competitors, especially HTML5. Today opened with a talk on making XForms work in HTML5 with browsers, followed immediately by a talk on replacing DocBook XML with XHTML5 (at O’Reilly). Two more abstract talks looked at filtering and an info space model, but the afternoon asked “Where did all the document kids go?” and then sought world domination by making XML invisible.
Organize and control content with the Lift web framework
Lift is a web framework built for the Scala programming language, running on the Java Virtual Machine. Version 2.5 recently shipped, and I’m highlighting features of the framework that I find appealing.
Last time it was transforms and REST services, and this time it’s two features around organizing and controlling access to content.
How do you manage the HTML pages on site? Maybe some pages are available to everyone, others require login or some condition for access, and often pages are grouped in some way. Lift has an optional mechanism for expressing all this in one place, and it’s called SiteMap. This is how it looks in code:
lazy val home = Menu.i("home") / "index" lazy val poets = Menu.i("poets") / "list" submenus ( Menu("Larkin") / "a-z" / "larkin", Menu("Tennyson") / "a-z" / "tennyson" ) LiftRules.setSiteMap(SiteMap(home, poets))
We’ve defined a site made up of a home page, and pages for poets we like. Why is this a good thing?
First, it’s a pretty readable representation of the site in (compiler checked) Scala code. You can probably figure out that we have a page called “home” found at /index.html (or / as it’s usually known).
What might not be obvious is that
Menu.i is using “home” as a key into your translation resources, meaning the link text will be the localized version—if you’re building an internationalized site. The link to the page can be generated by a
Menu.builder, a snippet you can use on pages to give your users navigation of the SiteMap.
The second menu item is called “poets,” served up from a template called list.html. On the home page, the navigation snippet would give you a link to the “poets” page, but by default is smart enough to hide the submenus until you visit the list of poets.
SiteMap also performs access control: if you use SiteMap, HTML pages have to be listed in it to be accessed. It’s a simple line of defense, but you can improve on this by adding location parameters. These are rules for controlling access to a page.
Let’s say we wanted to only offer some content to customers paying for our premium plan:
val PremiumCustomersOnly = If( () => false, () => S.redirectTo("https://shop.example.org/") )
This is an if-then-else construct, made up of two functions. The first function is a test for what qualifies as a premium customer. It’s an arbitrary computation, and in this example it’s
false, meaning nobody is a premium customer (in reality, we’d perhaps check a property of the logged user). If you nevertheless try to get to the page, the second function kicks in, and you’d be sent to our store front.
We can apply the “premium customer” rule to any part of the site, but we’re going to just restrict Tennyson poems:
Menu("Tennyson") / "a-z" / "tennyson" >> PremiumCustomersOnly
If you don’t like the
>> method name, use
rule instead. If you just don’t like this domain specific language (DSL), you can construct a SiteMap in longer-form method calls.
What’s great about SiteMap is the flexibility it gives you: if you can’t get the behavior you want out of the box, you can write custom functions and classes, and drop them into the SiteMap. If you want menus displayed in a completely different way, not handled by
Menu.builder customization, you can write a different navigation snippet. Location parameter rules allow you to isolate logic, and combine them as needed to parts of your site.
These blinders derail Drew Crawford’s detailed rant on Why mobile web apps are slow. It turns out that “slow for what?” is a key part of the question, as Crawford reveals near the very end:
It may also be true that the browser vendors have optimized their performance as far as they can, at least in the relatively stable fields of HTML parsing and processing, and CSS selectors and formatting. Adding
So how can we optimize mobile web development?
Windows 8 is mostly about touch.
There was a time, some fifteen years ago, when the choice of the programming language was a delicate decision. It stopped being a problem when .NET arrived. Because .NET languages compile to the Common Language Runtime, .NET compatible languages became more or less indistinguishable other than syntactically, and developers could happily mix Visual Basic with C# and even JScript.
In Windows 8, things are different.
A Windows 8 application runs on top of a new runtime environment—called “Windows Runtime” or WinRT for short. WinRT is a modernized and redesigned version of the .NET Common Language Runtime. You can write a Windows 8 application using C#, Visual Basic, or C++ for the logic and XAML for the layout. In doing so, you can take advantage of patterns that are made-to-measure for XAML, such as the Model-View-View-Model pattern (MVVM). In this regard, developing for Windows 8 is not that much different from developing for Silverlight or Windows Phone.