“But only the websites stupid enough to let them”
Most important part of this whole question.
“But only the websites stupid enough to let them”
Most important part of this whole question.
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.
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 . 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.”
Another fantastic article and an interesting read yes the apps are far easier to use especially for selling but recently I have been using the site to sell items as I can set correct postage values.
I find that with the apps it doesn’t let you set enough for postage and therefore you get stitched up with that for isntance a big text book on the app I think the maximum they will let you put for postage is for example £2 for the category yet postage for such an item is nearer £4
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
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.
No censure in webapps.
(not everything is about code or specs)
Just in case you valore it.
“[Apps] can be faster.” I agree with the premise, but it’s interesting that a lot of the time, apps happen to be slower than the websites. Case in point: The Facebook app takes forever to… well, do just anything at all. On a lot of devices, it’s so slow that it’s downright puzzling. I know and use a lot of apps that make me wonder, on a regular basis: “Just what are you doing there all this time?”
Jörg Stöver, I have to agree with you. This used to be a well written and though provoking blog but it has turned into drivel. Tablets killing PCs because of a high res screen? Web apps killing websites? Pfffft!. Removing this from my RSS reader