3 ms·

The main problem is getting it right for different screen sizes. Visual Basic GUIs mostly just worked well when your users had the same resolution as the dev.

lacrimacida 3y ago
Visual Basic GUIs were suitable for internal apps and tools and indeed easy to develop but that’s about it. There were many shortcomings to this technology and commercial apps werent built in VB. Their simplicity and ease of use are only useful as a contrast to today’s landscape. However, so many things have changed too, desktops not only try to be tablets, the web took the center stage and UI design also has become a confused mishmash of ideas.
badsectoracula 3y ago
Visual Basic 6 (and earlier) GUIs scaled fine for the most part since instead of using raw pixels they used "twips". In fact you can throw a bunch of controls on a VB6 form, compile to an EXE, change the compatibility settings for the executable to let it handle scaling, run it in a high DPI monitor and the controls, text, etc will scale as expected. AFAIK one place where it fails though is bitmap images - the "picture" container will be scaled but not the bitmap inside it (i think metafile images will be scaled though). VB was designed at a time when there were monitors not only with different DPIs but some didn't even have square pixels. Windows also had an option for "large fonts" even in Win3.x days which essentially increased the window scaling. IIRC dialogs defined via resources also use (or can use) the same approach, allowing them to be automatically scaled too. Of course in practice pretty much every application changed the coordinate mode to pixels and ignored the DPI settings, meaning not only the application didn't scale itself but it also didn't provide information for Windows to do the scaling. This is why more recent versions of Windows lie to applications about the DPI and do bitmap scaling of the window texture in DWM unless they explicitly (via a manifest file) claim they know how to scale themselves (or the user explicitly lets the application scale itself via the executable's compatibility settings).
- beeboobaa 3y ago
  There's more to responsiveness than scaling. Column based applications don't work on phones and rows of cards are terrible on desktop, just to name two examples.
lmpdev 3y ago
I wonder if there’s been work done to find the most “effective” ontology for targeting screen sizes Like Mark Weiser’s HCI work but down to the pixel/dot/vector size Surely it is better to target more than one screen size but it seems unlikely to be better to target dozens Any meaningful results more insightful than “4K, 1080p, 1024p 4:3, iPhone XYZ, popular Android resolution “ would be fascinating

lacrimacida 3y ago

Visual Basic GUIs were suitable for internal apps and tools and indeed easy to develop but that’s about it. There were many shortcomings to this technology and commercial apps werent built in VB. Their simplicity and ease of use are only useful as a contrast to today’s landscape. However, so many things have changed too, desktops not only try to be tablets, the web took the center stage and UI design also has become a confused mishmash of ideas.

badsectoracula 3y ago

Visual Basic 6 (and earlier) GUIs scaled fine for the most part since instead of using raw pixels they used "twips". In fact you can throw a bunch of controls on a VB6 form, compile to an EXE, change the compatibility settings for the executable to let it handle scaling, run it in a high DPI monitor and the controls, text, etc will scale as expected. AFAIK one place where it fails though is bitmap images - the "picture" container will be scaled but not the bitmap inside it (i think metafile images will be scaled though). VB was designed at a time when there were monitors not only with different DPIs but some didn't even have square pixels. Windows also had an option for "large fonts" even in Win3.x days which essentially increased the window scaling. IIRC dialogs defined via resources also use (or can use) the same approach, allowing them to be automatically scaled too. Of course in practice pretty much every application changed the coordinate mode to pixels and ignored the DPI settings, meaning not only the application didn't scale itself but it also didn't provide information for Windows to do the scaling. This is why more recent versions of Windows lie to applications about the DPI and do bitmap scaling of the window texture in DWM unless they explicitly (via a manifest file) claim they know how to scale themselves (or the user explicitly lets the application scale itself via the executable's compatibility settings).

beeboobaa 3y ago
There's more to responsiveness than scaling. Column based applications don't work on phones and rows of cards are terrible on desktop, just to name two examples.

lmpdev 3y ago

I wonder if there’s been work done to find the most “effective” ontology for targeting screen sizes Like Mark Weiser’s HCI work but down to the pixel/dot/vector size Surely it is better to target more than one screen size but it seems unlikely to be better to target dozens Any meaningful results more insightful than “4K, 1080p, 1024p 4:3, iPhone XYZ, popular Android resolution “ would be fascinating