4 ms·

>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

>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 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. 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).
    - papsosouid 14y ago
      >But context menu is a useful concept (sometimes). Of course. Which is why you would use it only where it is useful, not just hijacking a particular input event globally. >Thus web apps effectively lose one whole mouse button, thus reducing available input bandwidth. No, you can use right click all you want, and it need not interfere with the browser's use of right click. Also, very few people use a mouse on their phone, so this does seem like a bit of a stretch. >Another example of lost input is lack of system-global shortcuts. A web app in my knowledge can't have them. Right. There are a few other things like this that web apps can't do. And apps that people would want this sort of interface for should not be web apps. But as I said originally, virtually all the apps people use are not of that nature (and those that are almost always are apps that came with the phone), they are just websites turned into clunky, awkward apps for no reason. >except to get to web-app, you need to go through the browser first The browser is the app.

UnFleshedOne 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. 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).
  - papsosouid 14y ago
    >But context menu is a useful concept (sometimes). Of course. Which is why you would use it only where it is useful, not just hijacking a particular input event globally. >Thus web apps effectively lose one whole mouse button, thus reducing available input bandwidth. No, you can use right click all you want, and it need not interfere with the browser's use of right click. Also, very few people use a mouse on their phone, so this does seem like a bit of a stretch. >Another example of lost input is lack of system-global shortcuts. A web app in my knowledge can't have them. Right. There are a few other things like this that web apps can't do. And apps that people would want this sort of interface for should not be web apps. But as I said originally, virtually all the apps people use are not of that nature (and those that are almost always are apps that came with the phone), they are just websites turned into clunky, awkward apps for no reason. >except to get to web-app, you need to go through the browser first The browser is the app.