4 ms·
It's an overloaded umbrella term, largely for things that have existed for a long time, which inflates expectations for change.
by extension 15y ago
It's an overloaded umbrella term, largely for things that have existed for a long time, which inflates expectations for change.
- kennu 15y agoHTML5 is a convenient label for discussing and comparing other alternatives which also tend to have labels, such as Flash applications, desktop applications or native iOS applications. People will know what you mean in the broad sense, without specifying the exact CSS and JavaScript revisions and other extensions being used.
- extension 15y ago"HTML" or "web app" are equally convenient labels without the pretense.
- keeperofdakeys 15y agoSure, javascript, CSS and SVG have existed for a long time, but canvas, webgl, native video, CSS 3, new javascript apis and other things that bind all these together have only started trickling in. Some of them may still need improving, like audio, but that is changing over time. It is only now that you can contemplate building something complete with only the tools the stock browser provides.
- bradleyland 15y agoHere are two possible client interactions: ## CASE ONE Client: We want to build an HTML5 application for our customers to access our low-level educational books. Me: Ok, we can do that. My internal monologue: I understand that when my client says HTML5, they really mean a whole set of technologies. Client: Great, let's talk more about the idea! ## CASE TWO Client: We want to build an HTML5 application for our customers to access our K-6 educational books over the internet. Me: Oh, you don't really want 'HTML5' you want a single-page application written in HTML that uses Javascript to load client interface components in small pieces, rather than refreshing the whole page, and to drive reflexive interface elements that behave like traditional desktop applications. Also, we'll use CSS to style elements and use newer CSS3 features where available. Don't worry, the app will degrade gracefully in older browsers. We'll probably use a Javascript framework like Ember or Backbone coupled with a back-end web service built using Sinatra. How does that sound? Client: Ok, great. Well, we've got a few candidate firms to work our way through. Don't call us, we'll call you. You see, the guy in business building K-6 educational content can't also be in the business of building web applications. No matter how much you want to educate the world about your craft, it won't change one simple life lesson: you have choose what you'll be good at, because you can't be good at everything. Your clients know this implicitly. If they have the money to pay you, it means they're good at their business. Don't ask them to be good at your business. Buzzwords are abstractions for clients. They make our complicated technology accessible. They create a 'product'. This is good for our industry. If you're uncomfortable co-opting names for specifications, like HTML5, then you should propose something different, not simply complain about the abuse.
- extension 15y agoI propose one of the accurate terms that were already in common use, like "AJAX app" or "single-page app". But terms like these are constantly being replaced, to the great bewilderment of the client/lay person, in order to give the illusion of innovation. By using consistent terminology, we could avoid the translation step, along with the frequent conflicts caused by mistranslation.
- bradleyland 15y agoI also prefer the single-page-application description. I use the acronym form (SPA) once I've introduced customers to the idea. I scope projects like this: * You want a web app * The web app will be composed of components * Some components will be standard CRUD applications * Some components will be SPAs The "page refresh" is the cognitive anchor I use for clients. I tell them that standard CRUD applications are applications where the page disappears and refreshes when they click the save or submit buttons. SPAs are pages where things happen seamlessly on the page when they click buttons. I usually contrast their existing site to a site like Gmail. The thing is, I don't get in to this detail until we're past the opening conversation. During the opening conversation, my approach is to avoid correcting them at all. Rather, I ask for clarification of what they mean, then let them continue using their own terminology; abusive of our craft or not. I find that people are far better at explaining things in their own terms than they are trying to wrap them in our terms. Asking for functional examples (micro workflows) is a great way to understand what they really mean.