5 ms·

The need for responsive design. In 1990 you could make a pixel perfect design, that looked great on the 640 x 480 display that everyone used for everything. Tod

The need for responsive design. In 1990 you could make a pixel perfect design, that looked great on the 640 x 480 display that everyone used for everything. Today your application (i.e. your website) needs to look good on phones, tablets, laptops, etc.

steve1977 3y ago
But does it really? Because many of them don’t. They just look bad everywhere.
yason 3y ago
Using a better layout engine doesn't mean we couldn't have something similar. In the 90's there were adaptive layout engines that scaled UI elements according to set criteria as the window was resized or font sizes changed. Maybe not on Windows, but there's no reason VB couldn't have an adaptive layout for its UIs.
- deleted 3y ago
  [deleted]
- paulddraper 3y ago
  "Just automatically figure it out" sounds good, but in practice hasn't worked.
0xbadcafebee 3y ago
I just wanted to push back a bit on the idea that responsive design is a web innovation, or why we are where we are today. Here's a Visual Basic 6 tutorial from 2007 describing forms resized automatically based on screen size: https://web.archive.org/web/20100419123457/http://www.dreamincode.net/forums/topic/34776-resize-form-controls-for-screen-size-vb6/ https://web.archive.org/web/20100419123457/http://www.dreami... If native app ecosystems had as much invested in them (monetarily and people-hours) as the web ecosystem has, it would easily blow away anything you can currently do with a browser, and it'd be much easier. But investment got steadily and increasingly redirected to the web, while simultaneously progress was being held back by the limitations of the web.
- mr_toad 3y ago
  Partly this is because of enterprise security and procurement. You can invest all you like in the desktop, but getting anything new past change control is like flying to the moon.
- chrisco255 3y ago
  It's not just that forms need to resize. Mobile phones are entirely different computing environments, and VB never had a good answer for that. A mobile phone has different UI paradigms altogether, you cannot just resize a desktop app to a phone resolution and call it a day. You cannot be as precise with a thumb as you can with a mouse. You also do not have a keyboard, so anytime a user attempts to type into an input, a virtual keyboard will usually occupy almost 30-40% of the vertical space your app previously had. As a result it's much more difficult to even get a keypress from a mobile user, so you have to resort to alternative gestures and UI buttons to make up for this lack. This limits you to mostly lists and cards on mobile screens. You'll also be forced to reimplement or import a UI library that attempts to mimic things like app bars and navigation buttons that users expect from native mobile apps, as the web was never designed with these paradigms in mind. Native app ecosystems benefit from the fact that they are a singular computing and OS target. Web apps have to work on everything. It's the same reason gaming consoles tend to have a wider variety of AAA games than PCs. It's easier to optimize for the PS5 or Switch and call it a day, than it is to port a game to work on 6 year old video cards and get it to work on Mac (both ARM based and x86 based), Windows, and Linux. A web dev has to inherently target thousands of different devices, dozens of different operating systems, 3 or 4 browsers, and dozens of screen resolutions, and cannot make any assumptions about what type of input devices are available. Oh, and they also have to assume an async programming environment with intermittent connectivity, and possible throttled connections as low as 100-200 kbps, so try to keep the bundle size under 100KB to keep time to first paint under 1s, mmkay? Even Windows 95 apps could assume a few dozen MBs loaded in via disc, and count on cached assets being available on disk.
  - steve1977 3y ago
    > A mobile phone has different UI paradigms altogether, you cannot just resize a desktop app to a phone resolution and call it a day. So maybe mobile phones are just not meant to be tools for actual work, despite of what marketing departments of phone manufacturers tell us?

steve1977 3y ago

But does it really? Because many of them don’t. They just look bad everywhere.

yason 3y ago

Using a better layout engine doesn't mean we couldn't have something similar. In the 90's there were adaptive layout engines that scaled UI elements according to set criteria as the window was resized or font sizes changed. Maybe not on Windows, but there's no reason VB couldn't have an adaptive layout for its UIs.

deleted 3y ago
[deleted]
paulddraper 3y ago
"Just automatically figure it out" sounds good, but in practice hasn't worked.

0xbadcafebee 3y ago

I just wanted to push back a bit on the idea that responsive design is a web innovation, or why we are where we are today. Here's a Visual Basic 6 tutorial from 2007 describing forms resized automatically based on screen size: https://web.archive.org/web/20100419123457/http://www.dreamincode.net/forums/topic/34776-resize-form-controls-for-screen-size-vb6/ https://web.archive.org/web/20100419123457/http://www.dreami... If native app ecosystems had as much invested in them (monetarily and people-hours) as the web ecosystem has, it would easily blow away anything you can currently do with a browser, and it'd be much easier. But investment got steadily and increasingly redirected to the web, while simultaneously progress was being held back by the limitations of the web.

mr_toad 3y ago
Partly this is because of enterprise security and procurement. You can invest all you like in the desktop, but getting anything new past change control is like flying to the moon.
chrisco255 3y ago
It's not just that forms need to resize. Mobile phones are entirely different computing environments, and VB never had a good answer for that. A mobile phone has different UI paradigms altogether, you cannot just resize a desktop app to a phone resolution and call it a day. You cannot be as precise with a thumb as you can with a mouse. You also do not have a keyboard, so anytime a user attempts to type into an input, a virtual keyboard will usually occupy almost 30-40% of the vertical space your app previously had. As a result it's much more difficult to even get a keypress from a mobile user, so you have to resort to alternative gestures and UI buttons to make up for this lack. This limits you to mostly lists and cards on mobile screens. You'll also be forced to reimplement or import a UI library that attempts to mimic things like app bars and navigation buttons that users expect from native mobile apps, as the web was never designed with these paradigms in mind. Native app ecosystems benefit from the fact that they are a singular computing and OS target. Web apps have to work on everything. It's the same reason gaming consoles tend to have a wider variety of AAA games than PCs. It's easier to optimize for the PS5 or Switch and call it a day, than it is to port a game to work on 6 year old video cards and get it to work on Mac (both ARM based and x86 based), Windows, and Linux. A web dev has to inherently target thousands of different devices, dozens of different operating systems, 3 or 4 browsers, and dozens of screen resolutions, and cannot make any assumptions about what type of input devices are available. Oh, and they also have to assume an async programming environment with intermittent connectivity, and possible throttled connections as low as 100-200 kbps, so try to keep the bundle size under 100KB to keep time to first paint under 1s, mmkay? Even Windows 95 apps could assume a few dozen MBs loaded in via disc, and count on cached assets being available on disk.
- steve1977 3y ago
  > A mobile phone has different UI paradigms altogether, you cannot just resize a desktop app to a phone resolution and call it a day. So maybe mobile phones are just not meant to be tools for actual work, despite of what marketing departments of phone manufacturers tell us?