6 ms·
I disagree with the often-heard premise that HTML is a somehow inferior tool for creating GUIs that we somehow ended up with despite better choices beings avail
by BjoernKW 9y ago
I disagree with the often-heard premise that HTML is a somehow inferior tool for creating GUIs that we somehow ended up with despite better choices beings available.
Yes, native GUI frameworks and widget toolkits like Swing, Qt, Cocoa and MFC have their place but it's precisely the nature and features of HTML (most notably: The link) that enabled most of the innovation we've seen on the web.
If building web apps was just about recreating the desktop experience but on the web doing that with HTML indeed would be a fool's errand. However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers.
Sure, developing a web app today is not as easy anymore as "View source", edit and see what happens but it's still a lot more accessible than developing desktop-style applications.
In my opinion, instead of throwing the baby out with bathwater and replacing HTML with something else (which frankly and fortunately won't happen anyway because let's face it: HTML is here to stay for some time whether you like it or not) we should try and think about how to make web development easy and accessible again.
I think tools like StackBlitz ( https://stackblitz.com/ https://stackblitz.com/ ) are good first steps in that direction because they allow you to quickly try out and prototype stuff without having to care about setup and tooling.
What I'd love to see is the web equivalent of the C64 BASIC prompt, which provided you with an empty canvas to create something with right away.
- laythea 9y agoHTML is inferior than a technology that is purpose built. It was not originally designed to handle the job it does today. It is possible to create a much better user experience with eg. C# using some network code to talk to the server than trying to shoe horn an application over HTML just because it hides the low level complexities of E.g C#/C++ communicating with a server. This is a classic case of HTML/web apps are easier to produce (does that even make them inferior?) than custom built software, but it is more efficient to develop a web app, and therefore that is what business/industry has done.
- BjoernKW 9y agoHTML is not inferior it's different. In the late 90s some people said the same about Java and Java applets in particular. The UX of those however often was significantly worse than that of roughly equivalent (but at that time less dynamic) web applications. Apart from the usual benefits like being able to easily link to and consume resources HTML affords you a great deal of flexibility. Desktop UIs for very good reasons both follow OS-specific style guides and if cross-platform capable also have to settle for the lowest common denominator. As for your last point: Absolutely. Being accessible and easy to create perhaps is the single most important feature of HTML.
- laythea 9y agoIf you are trying to tell me that HTML was purpose built for the task that it does today, then I'm sorry but I do not agree.
- BjoernKW 9y agoTools can be used beyond the area they were originally intended for and still be useful and appropriate. Tim Berners-Lee probably didn't have single-page applications in mind when he invented HTML but hyperlinked documents are also inherently more dynamic and application-like than traditional documents. Just think about HyperCard, which is a similar concept HTML and the World Wide Web were inspired by. So, yes in a way indeed HTML was also built for many of the purposes it's used for today.
- sureaboutthis 9y agoC#, and maybe all programming language, are not designed for structuring documents inside a browser either. That is what HTML is for, not display or applications or communication, etc.
- laythea 9y agoI agree. HTML for documents. C# etc for applications.
- dvfjsdhgfv 9y ago> However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers. Could you elaborate on that? From the point of view of the user, an app from the 90s works much faster than Google Docs. From developer's point of view, using a visual widget in an app was as simple as dropping it on a form, and then setting some properties if needed, either visually or via code. Nowadays you can do it with Lazarus and it will generate code for different platforms. Look at this from another angle: The fact that the most powerful web company today with some of the most brilliant minds can't create spreadsheet software that would work equally fast as its desktop counterpart already says a lot about the tools we're using. Some people can't acknowledge it and miss the point completely and say "browsers are slow", trying all possible optimizations - but these are all hacks, not solutions to the underlying problem.
- BjoernKW 9y agoYes, the 90s app is faster but can it consume and provide data over a network? Does it afford collaborative editing? Sharing data with others? You can now even use Google Sheets for creating web applications much like Excel has been used for creating desktop applications. Lazarus and Delphi in general certainly are great tools but they're also limited in terms of what types of user interfaces you can create with them. There probably aren't many faster ways of creating single-user CRUD applications but once you have to roll out an application to multiple users who are supposed to use the application over a network and in a collaborative fashion things start to look different. As for the other angle I consider Excel (and the concept of spreadsheet software in general) one of the single most remarkable pieces of software created so far. Creating a fully-fledged spreadsheet application is no small feat. Then, let's not forget, Google Sheets is free whereas Microsoft makes significant revenue with their Office products, which would explain their motivation to create the best and fastest version of their product they possibly can while Google seems to be trailing behind.
- TeMPOraL 9y ago> Yes, the 90s app is faster but can it consume and provide data over a network? Yes, AFAIK, though I haven't used the features much. > Does it afford collaborative editing? That's a new one, but probably less difficult to bolt on top of a desktop app than to make a desktop app in a browser. > Sharing data with others? Yes! Current model is actually a huge regression here. On the desktop, you have a file system. You can share files. In the cloud, each application defines its own half-assed abstraction over data storage, and you're limited to what the service allows you and/or the company was bothered to implement. The problem with the web application is, unfortunately, a mix of multiple big issues. Browser becoming a worse-is-better incrementally evolved runtime for applications. A shitty technology (JS) used as the main language of said runtime. User-hostile business practices that became easy - and thus popular - to implement on the web. And the very popularity itself, which sucks out oxygen from more sane areas of computing and tries to port bad engineering everywhere.
- usernam 9y agoI'm not sure I've seen any "user interface innovation" done with HTML. Pick a book on GUI interfaces of the 80ies (for example: Computers Graphics by Foley & al), and see that pretty much all UI paradigms themselves were pretty much explored back then. The concept of the "hypercard" was already there. HTML just improved on the presentation of it, often worsening everything else. Somehow web apps lowered the expectations of what a computer /should/ do so much that usability itself became an afterthought. Some of the best designed apps on the web mostly ditch the DOM and layout everything in JS. Hardly "innovative".
- BjoernKW 9y agoI'd say that the web page itself is a pretty innovative concept. The concept might've existed before (Apple's HyperCard dates back to 1987 for example) but the web expanded on that by making use of resources distributed across the network. There have been many smaller improvements, too. Google's Material Design for instance.
- TeMPOraL 9y ago> There have been many smaller improvements, too. Google's Material Design for instance. Could you elaborate on that? I.e. how this is an improvement, and over what? Serious question. My overall impression is that it promotes dumbed down interfaces that maximize wasted screen space while minimizing amount of useful information displayed. But I might have just bad luck and constantly encounter applications using Material Design wrong. How does a good Material Design application look?
- BjoernKW 9y agoThe material metaphor and the purposeful use of animation ("Motion provides meaning"), dimensions and visual perspective in my opinion is an improvement over merely arranging information in grids. It's a fresh approach to displaying information in a meaningful and consistent manner. Both the new Google Calendar and Contacts application are decent Material Design applications in my opinion.
- graycat 9y agoWhen I'm a user, I like the old, simple HTML UI, and I've nearly always just deeply, profoundly hated and despised > the desktop experience To me, the whole "desktop experience" was based on some nonsense from Xerox PARC, that (1) the screen should be a metaphor for a traditional desk with several sheets of paper, (2) what was on the screen were representations of various objects that a user would manipulate directly using the pointing device, and (3) how the screen UI (user interface) worked should not be explained or documented but should be intuitively obvious, as obvious a sheet of paper on a real desk, and otherwise easy enough to learn just by experimentation. Well, for a very well designed UI for, say, a microwave oven, it worked, yet my microwave oven did come with a nice user manual. But for the goal of all of computing, IMHO, the Xerox PARC model and assumptions are a huge pain in the back side. E.g., for Microsoft's Windows Media Player 12 with Windows 10, I tried for hours, clicking, and clicking, basically enumerating and traversing all the UI before I finally resorted to my old favorite -- just put the mouse pointer, trial by trial, at nearly every point on the screen and there do four things, left click, right click, double left click, double right click, and see what happens. Don't look for any links, push buttons, controls and, instead, just throw clicks at the screen, exhaustively. Finally via such meaningless clicking, I was able to get some new options and, eventually, play an old audio CD but was not able to play a movie DVD. Some "user experience". To me, the situation is similar for a lot of common desktop software -- the UI is not described, documented, or obvious, and too often a LOT of experimentation is needed to figure out what the heck was going on. My UI Excedrin headache #948,223,594,667 was just last week with Outlook from Microsoft's Office. So, I wanted to use the old Microsoft command XCOPY, with some carefully selected options in a script in Rexx, to back up the directory tree that contains all of MY (not Microsoft's or HP's ) data on the computer, copy the directory tree to an external disk drive connected via USB (universal serial bus). So, I started the backup and in the morning discovered that the backup had failed. Failed? The computer and the external disk drive are quite new, and XCOPY and the options I was using are quite old and long perfect, so what the heck could have failed? I've been doing XCOPY backup and restores for 10+ years back to Windows 2000. Before that I was doing similar operations with similar software on OS/2 and then Prime computers. So, the last few lines on the screen explained the problem: The PST (personal storage or some such?) file that I have Outlook using was "locked". The actual message was the dreaded (from what can see via Google) File creation error - The process cannot access the file because another process has locked a portion of the file. So, but the only program that could have that file "locked" was Outlook, and as far as I knew it was not running. Then I looked at the output of the latest version of Microsoft's Task Manager (Windows 10 does have one although it is very different from what was on Windows XP) and saw that a program OUTLOOK.EXE was running. So, I told Task Manager to "kill" the program and started XCOPY again. So, then the XCOPY run worked fine! Then, presto, bingo, the next day trying to run Outlook gave Microsoft Office Outlook has stopped working A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. Well, I decided not wait for a notification!!!! I renamed that PST file and copied to the old name an old PST file and found that Outlook gave the same message. So, the problem was not the PST file. So, the bad memory Outlook was using about had to be in the Windows Registry. So, maybe I could do a system restore? Looking around, such is still available. So I did a system restore. Then Outlook started right away but also said that the PST file (the one Outlook was using before this mess) had not been closed properly or some such, checked the file, and found nothing wrong and now Outlook seems to be working again. So, before doing a backup, do a system save. For Outlook, try to have it not running. Why was Outlook running when I'd long since closed it? Okay, someone sent me via e-mail an appointment. A first ever for me. Of course, no way do I want Outlook involved in appointments. But, then, with that appointment, Outlook kept giving me notifications. The first backup attempt was actually after the appointment time and date, but somehow Outlook, when healthy again, reminded me again about the appointment. So, apparently if there is an appointment, Outlook will not stop but just keep running so that it can send notifications about appointments. So, before doing a backup, go into Outlook and delete, cancel, eradicate, obliterate, get rid of, destroy utterly everything about appointments. I JUST want Outlook to do e-mail, JUST e-mail, JUST simple, old SNMP (simple network mail protocol) and POP3 (post office protocol 3) e-mail. And, actually I want all the e-mail to be just simple, old ASCII text or UTF8. For more, use attachments as in MIME (multimedia internet mail extensions) with base 64 encoding, etc. So, for this cause and cure, are just throwing stuff against the wall, hoping, causing problems, getting into a system restore with some work lost etc. Bummer. Huge bummer. No, Xerox, Microsoft, your UIs are NOT "obvious". No, you NEED documentation. But, for old, simple HTML, say, without JavaScript, for some 100+ million such Web sites in the world, some trillion+ such Web pages in the world, and for 2+ billion people in the world, modulo natural language, every person can understand every Web page and Web site right away, no users manual or experimentation required. Lesson: On the desktop, the Xerox PARC stuff was an open door for chaos; on the Web, the simple HTML with its few, simple, well understood controls cleaned up much of the chaos and provided discipline that greatly helped UX (user experience). So, for the goal of having Web pages more like desktop applications, UIs, UXs, no thanks.