RSS
 

Posts Tagged ‘html5’

The Future of TodaysMeet

30 Jan

This is the second half of a two-part post. Start with part 1.

TodaysMeet is an interesting challenge because it has components that are absolutely real-time and should be built like a messaging system, not a CMS, and parts that aren’t real-time at all, and can totally be built like a CMS.

TodaysMeet has one loosely-coupled component, its Twitter integration. The site knows nothing about the daemon that executes Twitter searches and populates the database. If anything, I think it’s currently too loosely coupled, but it’s given me some insight into how to build the new system.

The guiding principles of this design are:

  • DRY. Only one part of the app should know about the canonical data store (MySQL for now).
  • Loosely coupled. A failure in one part of the service shouldn’t affect other parts.
  • Real-time, event-driven. Periodic polling is bad. Periodic Twitter searches are particularly so.
  • Use the right tool for the right job.

Obviously I’m a fan of Django. I could port TodaysMeet directly, using something like Playdoh to bootstrap the process, and get done relatively quickly. Django gets me a lot of stuff for free: a solid data store, users (something I want to add in a limited capacity, eventually), even a framework for building the crons and daemons necessary for running the site.

But Django is a lousy way to serve real-time content via long polling or socket connections.

I can easily serve real-time content via Node.js. I can do long polling or sockets. It’s also a great way to handle Twitter integration because I can just leave a connection to their streaming API, and handle new tweets as soon as they happen instead of checking periodically.

But even with things like Sequelize, MySQL connectivity through Node still feels awkward. (I think it will get better but I’m impatient.) And serving fairly static content is just weird.

So, Towelie, do you want to go real-time with Node, or do you want to use Django?

I’ll use… both!

Read on for a more technical overview. And a picture!

Read the rest of this entry »

 
Comments Off

Posted in Articles

 

Excitement about HTML5: Forms

22 Aug

I shouldn’t imply that I don’t like HTML5. I don’t like certain parts of it—the redundant new elements that add no functionality and are of little use except to A List Apart. But other parts of the spec are very exciting. Forms, in particular, are getting a much-needed facelift.

Forms will be able to require the user-agent to do pre-submission validation. Obviously we can’t rely on this for security reasons, but it will save us from writing JavaScript validation scripts and give users a better experience with our forms.

And the validation is fairly robust. <input/> elements gain an attribute called pattern, which accepts a simple regular expression, like "[A-E][0-9]{7}".

But you probably won’t need the pattern attribute very often, since there is a whole slew of new types that the UA will be expected to provide controls for, and validate. Crucial types, like email and url, and difficult types like datetime-local and color.

jQuery UI is great, but it doesn’t compare to this kind of power.

I only realized the sorry state of our current form controls very recently, after getting an iPhone. Built-in form fields on the iPhone can trigger different input methods. A field, like ZIP code, that accepts only numbers, opens the keyboard to the numbers first. A field that wants a URL can open a keyboard with a .com button to save time. But web pages can’t do this. They can only say that an input accepts arbitrary text.

For mobile or touch-enabled UAs, knowing that you can open a keypad instead of a full keyboard is a great step forward. For everyone, having date and color pickers built into the UA means saving both developers’ and users’ time. Less time to build and less time to download, consistent experience in the UA across web sites.

Forms also get a new event, input, which is a little like the current change event, except you don’t need to wait for the element to lose focus for the event to fire. That’s just useful.

Controls get new methods, stepUp() and stepDown(), to enable, for example, very fast forward/backward selection on a date input.

The last fun addition I’ll mention (go read the links, they’re all to the same page) is the autocomplete attribute. It doesn’t do what you hope it does. What it does is specify to the UA that it should not remember and suggest values for this input. It lets the UX designer decide whether to use Firefox or IE’s built-in autocomplete on a per-field basis. Useful. (Not as useful as, say, an autocompleteUrl attribute that could load some JSON or XML, but still useful.)

Building forms is going to be so, so much better once these are widely support.

 
Comments Off

Posted in Articles

 

Reservations about HTML5

08 Aug

A day or so ago, Adrian Bateman, from Microsoft’s IE team, posted his team’s thoughts on the current draft of the HTML5 spec.

Reading it is brutal. Bateman takes issue with basically everything added since HTML4. He goes through and individually criticizes many of the new tags, sometimes with extremely detailed, multi-paragraph critiques. I guess this is what happens when you’re not sufficiently involved at the beginning.

Of course, there is still plenty of time to complain, since the HTML5 spec won’t reach its final stage until 2022.

Bateman and the IE team, even while sounding like they don’t even want HTML5, do bring up a few things that have been bothering me about the spec.

Let me be very clear: I think new tags like <audio> and <video> are wonderful. Breaking the Adobe monopoly is great. There are still some issues (refusing to specify a codec meaning you can’t build support into the browser, for instance) but those types of tags are going to help push the web to a better place.

The parts that bother me are the new, highly touted “structural” tags, like <header>, <footer>, <section>, and worst, <article> and <aside>. Read the rest of this entry »

 
2 Comments

Posted in Articles