3 ms·
Could you give me an example of anything other than a game that is actually "taking advantage of the underlying hardware and OS" in some way that the browser ca
by papsosouid 14y ago
Could you give me an example of anything other than a game that is actually "taking advantage of the underlying hardware and OS" in some way that the browser can not? Looking at all the apps people use, games are literally the only things I've seen that aren't just poorly re-implemented websites.
- UnFleshedOne 14y agoInterestingly, I consider websites to be poorly reimplemented native applications. They make sense when there is a centralized database at the back, but even then UI and UX usually suffer. For one thing, they often lose input methods available to the underlying system. For example, how many web apps use context menus? How many _can_ use them without breaking browser's own UX?
- papsosouid 14y ago>but even then UI and UX usually suffer Because of bad designers. Most native apps suffer for the same reason. >For one thing, they often lose input methods available to the underlying system. Such as? >For example, how many web apps use context menus? How many _can_ use them without breaking browser's own UX? I have no idea how many do, but they don't break anything unless the designer messes up.
- UnFleshedOne 14y agoI've seen some sites overriding context menus to provide their own copy/paste commands (for unknown reasons, probably to change the look). In doing so, they remove all the options browser puts in there. For example, right now in Opera I have 17 entries in context menu when clicking on a empty spot on the page, 9 entries when clicking on selected text and 15 entries when clicking inside text edit field and yet another set when clicking on a link. Some of the options control behaviour of the browser, some deal with current page, some deal with specific page element. If HN wanted to use context menus for some app-specific reason, all of those options would be wiped out (at least for affected elements) because the app would be in direct conflict with the browser. Touch events are often another casualty -- sometimes they are commands to the OS (swipe to change active desktop), sometimes to the browser (pinch to zoom), sometimes to the app (drag to drag around a map, or maybe pinch to zoom?). Additional layers always introduce problems and cause things at the end of the chain to have worse UX or adapt by using lowest common denominator. A crazy example: gmail running in browser running in windows running in a windows VM running on a mac machine which is remotely connected via VNC from an android tablet. >:D Android -> VNC app -> OSX -> VMWare -> Windows -> IE -> GMail app. Ok, this doesn't illustrate much besides the point that browser _is_ an element of input chain (that makes a disproportionate effect on UX too -- the other links are at least trying to be transparent), I just like the idea. :)
- papsosouid 14y ago>I've seen some sites overriding context menus to provide their own copy/paste commands (for unknown reasons, probably to change the look). In doing so, they remove all the options browser puts in there. Of course, and you've probably seen much worse than that. Incompetent web designers are plentiful, but the capabilities of a web site are not limited to "broken sites made by incompetent designers". >If HN wanted to use context menus for some app-specific reason, all of those options would be wiped out (at least for affected elements) because the app would be in direct conflict with the browser. If HN wanted to do something incredibly stupid, they could do something incredibly stupid. Right. I'm not sure what the issue is there. If they wanted to not do something incredibly stupid, that is also an option. Why judge only on the worst possible scenario and assume every website is designed to be as broken and shitty as possible? >Touch events are often another casualty -- sometimes they are commands to the OS (swipe to change active desktop), sometimes to the browser (pinch to zoom), sometimes to the app (drag to drag around a map, or maybe pinch to zoom?). This applies equally to apps vs web, and isn't even specific to phones. >Additional layers always introduce problems and cause things at the end of the chain to have worse UX or adapt by using lowest common denominator That statement is false, and not relevant. The browser is no more an "additional layer" than an app is. The same number of layers in both cases.
- UnFleshedOne 14y ago> If HN wanted to do something incredibly stupid, they could do something incredibly stupid. Right. I'm not sure what the issue is there. If they wanted to not do something incredibly stupid, that is also an option. Why judge only on the worst possible scenario and assume every website is designed to be as broken and shitty as possible? But context menu is a useful concept (sometimes). It _would_ be nice if it could be used when it is called for. The problem is that it is impossible (I think) to use context menu or _any other right click action_ you could think of without breaking browser functionality. It would be like you said, incredibly stupid. Thus web apps effectively lose one whole mouse button, thus reducing available input bandwidth. Another example of lost input is lack of system-global shortcuts. A web app in my knowledge can't have them. I listen to music while I work and I tend to switch tracks or pause them once in a while. So when I listen to youtube playlists, I have to go back to the browser, open the playing tab and do it there. (and you never know if the video currently playing is SFW :)) > That statement is false, and not relevant. The browser is no more an "additional layer" than an app is. The same number of layers in both cases. The browser is a layer, and the native-app is a layer, except to get to web-app, you need to go through the browser first and a native-app sits at the same level as the browser (so a portion of input capabilities is not used up for the browser itself).
- woobar 14y agoInstagram and similar Navigation Shazam and similar
- papsosouid 14y agoInstagram? How is taking a picture something that can't be done with a browser?
- woobar 14y agoI am not sure what Mobile OS/browser gives acces to the camera control, but Instagram does more than takes a picture.
- papsosouid 14y ago>I am not sure what Mobile OS/browser gives acces to the camera control All modern mobile browsers do. >but Instagram does more than takes a picture. Be more specific then, I assumed that's what you thought couldn't be done. Tell me what it is you think can't be done so I don't have to guess.
- woobar 14y ago> Tell me what it is you think can't be done Actually, you did not ask about'what can't be done', but 'example of anything other than a game that is actually "taking advantage of the underlying hardware and OS"'. Instagram takes advantage of the underlying OS and hardware when it uses photo filters. Same as native games do. Could it be done in browser? Probably. Same as games.
- papsosouid 14y ago>Actually, you did not ask about'what can't be done', but 'example of anything other than a game that is actually "taking advantage of the underlying hardware and OS"'. You left off the rest of the sentence though, the part that said "in some way that the browser can not". >Instagram takes advantage of the underlying OS and hardware when it uses photo filters. Same as native games do. Could it be done in browser? Probably. Same as games. The difference is that photo filters can be done, quite trivially, in the browser. Many games can not, because the performance of the javascript engines and the limited hardware accelerated drawing.