By any other name

I’m not a fan of false dichotomies. Chief among them on the web is the dichotomy between documents and applications, or more broadly, “websites vs. web apps”:

Remember when we were all publishing documents on the web, but then there was that all-changing event and then we all started making web apps instead? No? Me neither. In fact, I have yet to hear a definition of what exactly constitutes a web app.

I’ve heard plenty of descriptions of web apps; there are many, many facets that could be used to describe a web app …but no hard’n’fast definitions.

One pithy observation is that “a website has an RSS feed; a web app has an API.” I like that. It’s cute. But it’s also entirely inaccurate. And it doesn’t actually help nail down what a web app actually is.

Like obscenity and brunch, web apps can be described but not defined.

I think that Jake gets close by describing sites as either “get stuff” (look stuff up) or “do stuff”. But even that distinction isn’t clear. Many sites morph from one into the other. Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

I think there’s a much more fundamental question here than simply “what’s the difference between a website and a web app?” That more fundamental question is…

Why?

Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think this same fundamental question applies to the usage of the term “HTML5”. That term almost never means the fifth iteration of HTML. Instead it’s used to describe everything from CSS to WebGL. It fails as a descriptive term for the same reason that “web app” does: it fails to communicate the meaning intended by the person using the term. You might say “HTML5” and mean “requires JavaScript to work”, but I might hear “HTML5” and think you mean “has a short doctype.” I think the technical term for a word like this is “buzzword”: a word that is commonly used but without any shared understanding or agreement.

In the case of “web app”, I’m genuinely curious to find out why so many designers, developers, and product owners are so keen to use the label. Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

In his recent talk at Port 80, Jack Franklin points to one of the dangers of the web app/site artificial split:

We’re all building sites that people visit, do something, and leave. Differentiating websites vs. web apps is no good to anyone. A lot of people ignore new JavaScript tools, methods or approaches because those are just for “web apps.”

That’s a good point. A lot of tools, frameworks, and libraries pitch themselves as being intended for web apps even though they might be equally useful for good ol’-fashioned websites.

In my experience, there’s an all-too-common reason why designers, developers, and product owners are eager to self-identify as the builders of web apps. It gives them a “get out of jail free” card. All the best practices that they’d apply to websites get thrown by the wayside. Progressive enhancement? Accessibility? Semantic markup? “Oh, we’d love to that, but this is a web app, you see… that just doesn’t apply to us.”

I’m getting pretty fed up with it. I find myself grinding my teeth when I hear the term “web app” used without qualification.

We need a more inclusive term that covers both sites and apps on the web. I propose we use the word “thang.”

“Check out this web thang I’m working on.”

“Have you seen this great web thang?”

“What’s that?” “It’s a web thang.”

Now all I need is for someone to make a browser plugin (along the lines of the cloud-to-moon and cloud-to-butt plugins) to convert every instance of “website” or “web app” to “web thang.”

Have you published a response to this? :

Responses

Kartik Prabhu

The Blogging DeadBlagofaire from xkcdReliable sources have finally confirmed that the blog is dead 1. According to Jason Kottke, the blog is dead, long live the blog. People seemed to be giving up on blogging and moving on to bigger and better things. Twittering (is that right?), Facebooking, Instagramming (one ‘m’ or two?), and Google+ing seem to be the hip-thing to do in 2014.So let’s look back and pay our last respects to the memory of Blogging.So what is blogging?I don’t know. I honestly don’t know.Blogging seems to mean different things to different people. Wikipedia, the modern sum of all human knowledge (no?), has an entry on Blog which nicely represents the state of affairs. The introduction describes a blog as a website with basically every feature or adjective under the sun.Blogs can be written by individuals, small teams, large corporations and think tanks. They can be about a single subject, a diverse range of topics, personal events and thoughts, brand advertising, or feature updates about a service or product. They can contain text, photographs, video, animations and illustrations. They can have comments and discussion by readers, or not. Blogging is not restricted by the kind of authors or type of content.So what is blogging?Jason seems to distinguish the ‘blog format’, the reverse-chronological stream of posts that blogs traditionally have. Even though most blogs use the stream format to present a list of posts, this is a UI decision. It works nicely for some kinds of content—periodic photography posts (Street Photography by Sagi Kortler, Streets of Athens by StamatisGR), personal diary, product/service updates (Gridset Blog, Building Feedly). I don’t think the stream works for sites with a lot of eclectic topics; I don’t really like the stream nature of the archives of this site, but I don’t have any better ideas yet (suggestions welcome!). Blogging is certainly not restricted to the time-stream format 2.So what is blogging?Is blogging just writing?For a long time blogging was a derogative for writing on Web. If you wrote on the Web, you were a blogger, not a ‘real’ writer; it was a blog post, not a ‘real’ article; it was blogging, not ‘real’ journalism 3. Blogging was, simply put, bad writing.I hope that in 2013, it is clear that this was an asinine point of view. This type of blind bigotry against content just because it lives in a different medium is still rampant (comics vs. real literature, anyone?); but it seems we have finally accepted content on the Web as a legitimate form of writing.A book is no longer considered bad just because it is digital or on the Web 4. Comics on the Web have received wide acceptance. The success of House of Cards has finally shattered the perception that good drama can exist only on film and television 5. Lot of mainstream magazines and newspapers are now online. Many scientists write blogs about their research 6.Good content is good content, regardless of the medium. The Web is a global, open, accessible, flexible medium for writing content; and writing on the Web is not bad writing. Blogging is not a dirty word anymore.So what is blogging?Blogging is, simply put, writing on the Web. Blogging is not some special exotic activity that suddenly everyone gave upon (planking?), it is just writing on the Web. People have been writing on the Web long before 1997 (the birth year that Jason put on the Blog’s epitaph).1997 was around when web-publishing tools became accessible to the not-so-technical crowd. Everyone and their mother started writing on the Web, and called it a ‘blog’; a portmanteau of web and log. Later as people realised that blogging was not just about choosing a peppy website name, a snazzy visual theme and cool widgets; and that you actually had to write good, interesting content, most people gave up. The blogging fad died, slowly and painfully, exactly because people realised that blogging was about writing—and that it demanded hard work, lots of thought, sometimes multiple edits, just like ‘real’ writing. Most people who had jumped on the blog bandwagon were simply not prepared to do this work. It is much easier to follow on Twitter, ‘like’ on Facebook, reshare on Google+, than it is to create and write interesting content yourself. We have become passive followers rather than active creators.The people who stayed with active writing either, enjoyed the process (like me) or had been writing on the Web before ‘blogging’ became the it-thing. In fact, a lot of these folks no longer refer to their writing as blogs. Mark Boulton, Craig Mod, Jeremy Keith have journals, while Randall Munroe has a xkcd blag. Jeffrey Zeldman prefers to just call it a website!Of silos and walled gardensJason also seems to use the word blogging to distinguish writing on your own website from writing on silos (Facebook, Tumblr, Medium, Google+… ).The tightly-integrated walled garden that these silos provide is very, very tempting compared to the wild, anything-goes, shoot-from-the-hip nature of the open Web. If you write on these silos you are given easy access to a large audience along with plenty of easy-to-use tools for sharing. But, you also miss out on the people who don’t live in your particular walled-garden. Should you post multiple copies of your content on every silo? Should you update all of them and keep them current?The most problematic aspect of this is that there are only copies, no original! If in the future someone wants to read your content, in which silo should they look for the best representation?Another issue I have is conformity. Every tweet, post on Facebook looks and feels exactly the same. Medium, for instance, seems to exert a lot of control on how its articles look. While it helps to exert some quality control, this makes the platform very restrictive 7.What happens when one of these silos shuts down? Imagine if every time a popular book publisher closed down, every copy of all the books they ever published just disappeared. What a disaster! That is the situation with writing on silos. Sure, they might give you a backup copy of all your posts, but then you’d republish them on another silo and the cycle begins anew. It is much better to publish on your own site as the canonical version and syndicate copies elsewhere aka POSSE.In this sense, the blog isn’t dead. It is just sleeping or the blog might be dying, but the web’s about to fight back.ReawakeningBlogging is not a form, not a style, not a UI format, not a medium. It is a made-up buzzword like Web2.0 or web-app 8. Blogging, the buzzword might very well have lived from 1997-2013. As for writing on the Web, it has existed as long as the Web has, and will continue to do so.As of today, people are increasingly turning to walled-garden silos to host their content. If the death of blogging means the end of a fad, of a buzzword, of bad writing then I am all for it. If, on the other hand it means the end of original writing on the Web, or writing solely on silos, I really hope ‘blogging’ rises back from the dead to haunt us.In any case, let’s not ‘blog’, let’s just write—on our own personal place on the Web.Notes & ReferencesMore on ‘Blogs being dead’: The blog is dead, long live the blog and R.I.P. The Blog, 1997-2013 by Jason Kottke.The Death of the Blog, Again, Again by John Scalzi.The blog isn’t dead. It is just sleeping. by Colin Devroe.The blog might be dying, but the web’s about to fight back by Ben Werdmuller.This is a website by Jeffrey Zeldman.Blogging and UI: Weblog Weirdness by Eric Meyer.Blog Interface Design 2.0 by Luke Wroblewski.Blogging and journalism: Is Blogging journalism? by Paul Andrews.Blogging vs. Journalism: The Ongoing Debate by Jacob Friedman.the transition to digital journalism by Paul Grabowicz.Books on the Web: The Feynman Lectures on PhysicsButterick’s Practical TypographyThe James MacTaggart Memorial Lecture 2013—Kevin Spacey about the paradigm-shifting success of House of Cards.Blogs by scientists: What’s new by Terry Tao.Not Even Wrong by Peter Woit.One Universe at a Time by Brian Koberlein.Musings by Jacques Distler.Azimuth by John Baez.This restrictive post format is one of the main reasons I moved to own site. I would not be able to post a lot of things I have here, on Medium or Facebook or Google+.Webapp or not: By any other name and Defining the damn thang by Jeremy Keith.Poll Results: “Sites” vs “Apps” by Chris Coyier.

Aaron Gustafson

Ars Technica revealed today that Comcast is injecting self-promotional advertising into web pages delivered via it’s Wi-Fi hotspots:

A Comcast spokesman told Ars the program began months ago. One facet of it is designed to alert consumers that they are connected to Comcast’s Xfinity service. Other ads remind Web surfers to download Xfinity apps, Comcast spokesman Charlie Douglas told Ars in telephone interviews.

I wish I could say this is surprising, but it’s not: Any service that routes your content has the opportunity to modify the response being returned. Comcast is exploiting that opportunity and injecting JavaScript that, in turn, injects the ads.

The fact that middlemen can manipulate server responses is one reason Google is pushing for all sites to be served under HTTPS. With traffic running to and from your server in an encrypted fashion, man-in-the-middle attacks—which, if we’re honest, is what this amounts to—become much more difficult.

Assuming you can’t run under HTTPS for one reason or another, how do you harden your web thang against 3rd party manipulation you can’t control? What if Comcast’s JavaScript interferes with your own? Remember when Sky blocked jQuery for all of their customers? That was a bad couple of hours for most UK-based internet users.

Comcast’s move only serves to remind us—yet again—that we don’t control how our sites are delivered or what our users see. Or rather we do, but only up to a point. So rather than focus on some ideal experience we expect everyone to have, we must focus on building great experiences that work in a variety of contexts and situations.

We need to develop the 1964 Chrysler Imperial of websites: Sites that soldier on even when they are getting pummeled from all sides. After all, browsers, plug-ins, users, networks, and, yes, even the very routers that deliver our connections all have a say in how (and what) content gets to our users.

I’ll leave you with this scary quote from the Ars piece:

Security expert Dan Kaminsky said in an e-mail that JavaScript injection has the potential to break “all sorts of stuff, in that you no longer know as a website developer precisely what code is running in browsers out there. You didn’t send it, but your customers received it.”

Hooray!

Aaron Gustafson

Ars Technica revealed today that Comcast is injecting self-promotional advertising into web pages delivered via it’s Wi-Fi hotspots:

A Comcast spokesman told Ars the program began months ago. One facet of it is designed to alert consumers that they are connected to Comcast’s Xfinity service. Other ads remind Web surfers to download Xfinity apps, Comcast spokesman Charlie Douglas told Ars in telephone interviews.

I wish I could say this is surprising, but it’s not: Any service that routes your content has the opportunity to modify the response being returned. Comcast is exploiting that opportunity and injecting JavaScript that, in turn, injects the ads.

The fact that middlemen can manipulate server responses is one reason Google is pushing for all sites to be served under HTTPS. With traffic running to and from your server in an encrypted fashion, man-in-the-middle attacks—which, if we’re honest, is what this amounts to—become much more difficult.

Assuming you can’t run under HTTPS for one reason or another, how do you harden your web thang against 3rd party manipulation you can’t control? What if Comcast’s JavaScript interferes with your own? Remember when Sky blocked jQuery for all of their customers? That was a bad couple of hours for most UK-based internet users.

Comcast’s move only serves to remind us—yet again—that we don’t control how our sites are delivered or what our users see. Or rather we do, but only up to a point. So rather than focus on some ideal experience we expect everyone to have, we must focus on building great experiences that work in a variety of contexts and situations.

We need to develop the 1964 Chrysler Imperial of websites: Sites that soldier on even when they are getting pummeled from all sides. After all, browsers, plug-ins, users, networks, and, yes, even the very routers that deliver our connections all have a say in how (and what) content gets to our users.

I’ll leave you with this scary quote from the Ars piece:

Security expert Dan Kaminsky said in an e-mail that JavaScript injection has the potential to break “all sorts of stuff, in that you no longer know as a website developer precisely what code is running in browsers out there. You didn’t send it, but your customers received it.”

Hooray!

Aaron Gustafson

Ars Technica revealed today that Comcast is injecting self-promotional advertising into web pages delivered via it’s Wi-Fi hotspots:

A Comcast spokesman told Ars the program began months ago. One facet of it is designed to alert consumers that they are connected to Comcast’s Xfinity service. Other ads remind Web surfers to download Xfinity apps, Comcast spokesman Charlie Douglas told Ars in telephone interviews.

I wish I could say this is surprising, but it’s not: Any service that routes your content has the opportunity to modify the response being returned. Comcast is exploiting that opportunity and injecting JavaScript that, in turn, injects the ads.

The fact that middlemen can manipulate server responses is one reason Google is pushing for all sites to be served under HTTPS. With traffic running to and from your server in an encrypted fashion, man-in-the-middle attacks—which, if we’re honest, is what this amounts to—become much more difficult.

Assuming you can’t run under HTTPS for one reason or another, how do you harden your web thang against 3rd party manipulation you can’t control? What if Comcast’s JavaScript interferes with your own? Remember when Sky blocked jQuery for all of their customers? That was a bad couple of hours for most UK-based internet users.

Comcast’s move only serves to remind us—yet again—that we don’t control how our sites are delivered or what our users see. Or rather we do, but only up to a point. So rather than focus on some ideal experience we expect everyone to have, we must focus on building great experiences that work in a variety of contexts and situations.

We need to develop the 1964 Chrysler Imperial of websites: Sites that soldier on even when they are getting pummeled from all sides. After all, browsers, plug-ins, users, networks, and, yes, even the very routers that deliver our connections all have a say in how (and what) content gets to our users.

I’ll leave you with this scary quote from the Ars piece:

Security expert Dan Kaminsky said in an e-mail that JavaScript injection has the potential to break “all sorts of stuff, in that you no longer know as a website developer precisely what code is running in browsers out there. You didn’t send it, but your customers received it.”

Hooray!

Josh Wedekind

@adactio A near universal understanding that’s hard to define. Much like using the words “brunch” and “obscenity.” ;-)

Andy Budd

@adactio @t Mostly because I like words to have definitions. Otherwise they’re just a series of meaningless sounds ;)

# Posted by Andy Budd on Saturday, January 3rd, 2015 at 1:23pm

Jeremy Keith

@andybudd @t I think that “just a series of meaningless sounds” is a very good definition of the term “web app.”

Andy Budd

@ScottKellum bit like saying “they’re all just fruit, so bananas and apples seem like needless differentiation.”

# Posted by Andy Budd on Saturday, January 3rd, 2015 at 3:45pm

Eoin Kelly

@adactio My frustration with “just use progressive enhancement” is that it is currently a lot more complex. There is no prior art …

# Posted by Eoin Kelly on Friday, January 23rd, 2015 at 9:54pm

Dafydd Thomas

@adactio Difficult, I agree. I guess: Trello/Gmail/Messenger == web app. Wiki, Twitter, my person site == website.

Richard Nash

@adactio in my opinion, it’s a continuum, not a dichotomy. From static to dynamic with varying levels of both from one end to the other…

Jason Garber

Hello! My name is Jason and I’m a Web developer. I spend most of my time building websites with HTML, CSS, and JavaScript. I’m pretty good at Ruby, too. This will totally date me, but I’ve been tinkering on the Web since the mid-90s and, like many folks from that era, managed to spin a hobby into a decent career. While I have an interest in the entire process of building, designing, and testing Web-based things, I spend most of my work life tapping codes into computers.

I joined the United States Digital Service (USDS) back in April and currently work with my teammates at the Defense Digital Service (DDS). Alongside United States Transportation Command (TRANSCOM), we’re taking a fresh look at a sprawling mass of software and processes that over 400,000 military families use each year to coordinate movement of their household goods from one duty station to the next. We’ve heard the moving process described as the most stressful time in a service family’s life, second only to the stress of combat deployment.

For all my time spent at startups, agencies, and large corporations, I’ve rarely been involved in “design” activities such as user research, sketching sessions, and prototyping. Over the years, I’ve advocated for involving engineers throughout the design process. But while many managers pay lip service to the concept, when the rubber meets the road, organizations tend to prefer that their expensive engineers spend their time writing code. This attitude reinforces inefficient waterfall processes, prevents empathy building, precludes knowledge sharing between engineering and users, and results in lower-quality products.

As luck would have it, one of USDS’ core values is, “design with users, not for them.” In that spirit, I recently joined my DDS teammates in sunny O’Fallon, Illinois for a week-long design sprint.

Go where the work is.

We organized a Google Ventures-inspired design sprint by gathering a select group of service members, military spouses, civilian support staff, designers, and engineers with the goal of addressing some of the system’s most critical usability problems. We divided the group into six project teams, each tasked with developing a prototype that addressed a specific question around the theme of, “What would the moving experience look like if…?” Topics ranged from reimagining the inventory process to revamping the experience of visiting a transportation office.

The days were long and my brain nearly turned to mush, but I’m happy to report that by the week’s end, each team had successfully generated storyboards, produced prototypes, and tested their designs with military families. While working on a project team, I learned quite a bit about how an engineer can help organize, facilitate, and contribute to a successful design sprint.

Design with users, not for them.

I’ve wrestled with adequately capturing in words my enthusiasm coming out of the design sprint. I can’t understate the value I derived from being in the thick of the design process, sitting shoulder-to-shoulder with others deeply invested in improving such a critical system. I’ll do my best to highlight a handful of things I took away from the week’s activities.

One Conversation at a Time

This one is critical. Design sprint activities are purposefully time-boxed to drive project teams toward quick-and-dirty prototypes. In this hectic environment, side conversations could subdivide the group and divert attention from the task at hand. As one of two facilitators on my team, I had to gently—but firmly—keep sidebar conversations to a minimum. This wasn’t much of an issue in my project team, but it’s important to keep in mind.

Manage a Parking Lot

Before this design sprint, I wasn’t familiar with the meeting management concept of a “parking lot.” Basically: capture ideas or lines of conversation tangential to the meeting’s purpose in a “parking lot” for future recall and discussion. In the context of a design sprint, and given the haphazard nonlinear idea generation process, maintaining a parking lot will help the group focus without scrapping useful tangential ideas.

Ask Questions

As ideas flowed fast and furious, I found that asking plenty of questions helped the project team determine which ideas we should pursue, which we should discard, and which we should add to the “parking lot.” By asking plenty of questions, I was able to make sure I had the time to fully understand my teammate’s idea or position. Being asked questions by my teammates kept me on my toes and gave me the chance to refine and solidify an idea or position.

Listen Intently

With the clock running, adrenaline pumping, and ideas flowing, I found it difficult to quiet my mind and really listen to my teammates. My brain was in overdrive coming up with possible solutions when it should have been listening to what my teammates were sharing. Remaining mindful of my own inner voice and actively listening to others was a struggle, but a worthy one.

Create momentum.

We heard repeatedly from participants how much they enjoyed contributing and how excited they are to see their solutions considered for implementation. Some of these folks have served their country or worked in government for literal decades. They related how, in the past, they’d offered solutions to the problems we’re addressing only to watch their ideas fail to gain traction. I’m humbled by the tenacity of those who, despite the relative ease of cynicism, so freely participated and shared their experience.

I’m also grateful for the chance to take part in this design sprint. I was able to exercise a set of skills I don’t normally flex in my regular project work. The week’s activities also built empathy with the military families affected by the current systems and processes. For a brief moment, they opened to us a window into their lives. We demonstrated that cross-functional teams—designers, engineers, and users—could rapidly design, prototype, and test solutions to some of the system’s most critical usability problems.

I fully intend to participate in future design sprints and will continue advocating for an engineer’s role in the design process. If you’re an engineer, I’d encourage you to speak up when you next hear about an upcoming design sprint. If you’re a designer or project manager, include the engineers on your team as you plan out your next design sprint. Together, we—designers, developers, users—can create compelling solutions to critical challenges.

For more examples of governments using the design sprint model, check out the following Sprint Stories case studies:

Many thanks to James Athey, Justin Ellsworth, Jordan Kasper, Reina Staley, and Elliott Wilkes for reviewing an early draft of this post.

4 Likes

# Liked by Everywhere on Tuesday, October 21st, 2014 at 9:31pm

# Liked by Matthew Ellis on Sunday, January 4th, 2015 at 1:42am

# Liked by ✪ Felippe on Wednesday, February 10th, 2021 at 4:38pm

# Liked by Austin Gil on Wednesday, February 10th, 2021 at 4:38pm

Related posts

Defining the damn thang

We must go deeper.

Related links

The Website vs. Web App Dichotomy Doesn’t Exist | jakelazaroff.com

Amen!

If there’s one takeaway from all this, it’s that the web is a flexible medium where any number of technologies can be combined in all sorts of interesting ways.

Tagged with

Robin Rendle ･ Web Apps Are Not A Thing, Please Stop

Right?

Tagged with

Poll Results: “Sites” vs “Apps” | CSS-Tricks

Some excellent research from Chris, canvassing opinions on whether there’s a difference between web “apps” and web “sites”. His conclusion:

Almost none of the points above ring true for me. All I see are exceptions and gray area.

If nothing else, the fact that none of the proposed distinctions agree with one another show how pointless the phrase “web app” is—if people have completely differing ideas on what a phrase means, it is completely useless in furthering discussion …the very definition of a buzzword.

This leads me to think perhaps the “web app” moniker (certainly the newer of the two) is simply just a fashionable term. We like the sound of it, so we use it, regardless if it truly means anything.

But all of this is, I think, missing the more important point: why? Why would you want to separate the cornucopia of the web into two simplistic buckets? What purpose does it serve? That’s the question that really needs be answered.

If we could pin down a super accurate definition that we agreed on, even then it might not be particularly useful. And since we can’t, I argue it’s even less useful.

The most accurate (and damning) definition of a “web app” that I’ve heard so far is: a web site that requires JavaScript to work.

Tagged with

Previously on this day

23 years ago I wrote UK awaits Star Wars première

I’ve had my ticket for over a month now and I’ve resisted the urge to turn this journal into one long countdown. Now, though, the excitement is official.