Will Apps Kill Websites?

With LastPass, I can give each site a very strong, unique password that I never have to remember or transcribe.

I have yet to see an app, whether mobile or desktop, that plays nice with LastPass.

wow wait a minute. As a developper I have the choice to build a web app to replace an old website and ship as a native app on multiple platform( www.phonegap.com ).

What you point out in your article is just a cleaner interface in the newest app. They will soon realize to redesign their website.

I guess I’m in the minority preferring the website.
I look at it and see a large number of features that I would and do use, which aren’t present in the app.

People talk about the 80/20 rule and how everyone only uses 20% of the features. The problem is that for each person it tends to be a different 20% and cutting it down to the lowest common denominator will get a lot of people miffed. I have seen too many apps of websites I use made “simple”(dumbed down) and lose all the functionality I like in them that allows me to save clicks and time. I need to make multiple clicks to get to whatever function I want, and having to deal with a tiny screen and buttons that when next to each other are easily mispressed, the whole app experience is consistently poor for me, and I am constantly impressed by the patience of people that suffer their way through playing around on their phone when they have a pc terminal right next to them.

Webapps won in the '00 because one didn’t have to install anything. JavaScript capable web browser was all you needed. Compare this to native applications, where you had to go to the store, buy a CD, than install it and last but not least take care of your data and updates.

But now you have 3 major and 2 minor browsers. And mobile browsers. You have to support different versions of those. So you choose jQuery or some other library to keep things somehow universal, but it’s another layer you have to worry about. And if you are writing software for corporations, someday they will say “Browser X is our weapon of choice. Don’t spend extra dollars to support some hippie browser, we pay, and we demand your stuff to work with MSIE 8. And don’t even start with chromes’ continuous delivery. It’s forbidden. Forbidden.”

And let’s face it, hypertext wasn’t really meant for applications. The whole industry of webapps was based on some clever hacks and universal web browser. One browser to rule them all so to say. Ask your UX developer, it’s no longer the case.

TechCrunch wrote 4 days ago about Facebook struggling with Apple and Google about future of html5 mobile web browser. http://goo.gl/jSe4d Quotation: "Apple and Google have a vested interest in seeing HTML5 lag behind native apps. " (but read the whole thing). So you won’t have a web application that “fells” almost like native one anytime soon.

A web application that “fells” almost like native one. So, why the hell stay with the “almost like” and accept the imitation, where you can have the real thing?

Current native apps will see your camera, gps, gyroscope, and what have you. Your UX people will be happy doing less hacks and more real work. Your IT department will alone decide when they will publish a new version. They don’t have to catch with the development of Chrome or Firefox.

Webapps will prevail thou. As simple version of much cleaner, better experience App can give. When you’ll start a new relationship with some service, you’ll probably will start with a browser. That’s the first and second date. And if you are happy with it, and maybe want to move on to the next base (pardon me), you’ll install the app. That’s the sign of confidence you put in it. On the other side, full blown webapps with anything and kitchen sink will be like “we are good friends and that’s why we live 30 years together, but we don’t trust each other so much to have one fridge.”.

What does it mean for the developers? APIs. With a good api you can power a web application with all its quirks, or you can build a set of applications for many different devices. Like netflix. Or dropbox.

Webapps (user experience) aren’t sexy anymore. I see more and more developers going full time to the server stuff (scalability, clouds, apis), or programming lots of lots cheap native apps. With a little luck they can create a photo app and sell it for 1 gigadollar to Marc Z :wink: . This leaves the web front ends for someone else to do. This gap can’t be easy filled.

And one personal observation at the end: with native apps i fell much less procrastinating than with the browser. Browser is one million pages waiting to be opened. Native app is one task to be done.

To be honest, I’m a bit disappointed that this generally high quality blog still stoops down to childish, sensational stuff like this. No, apps won’t kill websites. Just like websites didn’t kill applications. And consoles didn’t kill PC gaming. And handheld devices didn’t kill the desktop PC. And Linux didn’t kill Windows.

Making unsubstantiated claims like that is a short sighted way to get some free extra traffic. It undermines any sense of integrity and expertise the readers place in a blog like this.

@Juhani I much prefer the website version as well, and don’t find the interface especially ugly either. There is much more screen real estate and the website makes good use of it, for example by having filter settings down the sidebar instead of hiding them behind a “Refine” or “Advanced” button.

The eBay mobile apps really fall down when you go to view the listing details. Depending on the lister and their auction management software, some of them rely on Flash, and this is invisible on iDevices and doesn’t seem to work very well on Android (at least in my browser it thinks I don’t have Flash installed when I do). Others have a lot of custom HTML formatting which is either stripped out or rendered poorly in the mobile app. This is not the apps’ fault, but it makes it impractical to use it to actually buy things on eBay.

“It’s not so much that the eBay apps are great, but that the eBay website is so very, very bad.”

You might find this Google presentation interesting:


The eBay application lacks the most important feature I need when I’m looking for something on eBay: tabs. I usually search for an item, then I middle-click each item that seems interesting, then I switch to the tabs that have been opened in background to analyze them.
Without a tabbed interface, you have to show and item, then go back, show the next item, go back, and so on. You can’t easily and quickly switch between two items to compare them.
This is a common issue with almost all the smartphone/tablet application compared with the browser-based version.

“The implied lesson here is to embrace constraints.”

Oy. I pretty much stopped reading here. This is what people said during the Great Transition from client-side applications (or client-server applications) to the web.

I think the lesson is: embrace self discipline and good software engineering practices, in spite of the sexy new hotness of whatever latest technology or paradigm that comes along that’s going to solve all your problems without the need for tedious thought.

I would add that in addition to the “Lord of the Flies” design choices that must be made when creating a mobile app that these experiences are experiences. Not only are you simply navigating through your options, but you are interacting with them. I would argue that the experience of swiping, zooming, and panning allow the user to get up-close and personal with their interactions.

That having been said - and especially in the case of eBay - it’s really nice to have an auction (or search) open in one window while researching the widget of the day in another.

But apps will always need websites, if for nothing else other than a source of data, as a mothership to phone home to, and a place to host the application downloads for various devices.

Nope. All they need is an API they can talk to, which need not use HTML at all, or be visible in a browser. (And downloads? That’s what a store is for.)

Now, I agree that they’re not going to remove the need for websites for other reasons - but they don’t depend on them, strictly.

I don’t know - I think the line between apps and websites are getting pretty blurry.

I think a lot of this thinking is somewhat limited. CSS has had the ability since forever to define different representation models for different media - getting different representations for print and screen, for instance, without changing the underlying HTML.

So why not have more support for listing Android under media? Or iPhone or iPad? Something like

@media ipad{

With appropriate API guidelines published, establishing different tags as different common UI elements that can have their visibility hidden or otherwise changed for other platforms, I see no reason why someone couldn’t literally download an HTML5 app for any device. Users can be certain that the app will run regardless of what platform they run, and the enhancements will just work if you have an “officially supported” platform.

Where things could REALLY get interesting is if Apple or Google started to treat HTML as the UI language that it is, writing compilers that take HTML written according to API and transforming it to native UI code to get the speedups that native code provides. Add industry pressure for hardware optimization for Javascript and we would finally start to get truly universal applications.

No censure in webapps.
(not everything is about code or specs)

Just in case you valore it.

Apps are really annoying imho. They sometimes come in handy, but they don’t pack all the features a regular site has.

Normally, I even have trouble trying to figure out how they work.

Dayo Search

Of course, then there’s the middle ground, with sites like Fuelly that have an AMAZING mobile site (at least, for phones, never visited their site on a tablet) which is basic and easy, and a solid desktop site with more information, etc (and an easy way to switch between the two from your mobile device)

Nice article. I think both will continue to exist just as websites and desktop apps co-exist. I think in time as mobile devices continue to get more powerful the argument for dedicated apps will get tougher. Building a website that works every where seems like a much better idea than building a website and several different versions of an app!

Actually, with html5 related technologies it is possible to create “offline” websites, even though there are still some issues (for instance, in iOS we can’t cache sound files yet). Thus, “They work better on the go and even offline” isn’t really a app pro. On the other hand, apps have access to a broader set of device-specific features (for instance, tilt sensors), so that’s another pro.

Everything old is new again. What was once a centralized mainframe with dumb terminal front end, evolved to the client server model, evolved to web server and browser, moves again to a client application. The more things change, the more they stay the same.