An accessible UI that honors the platform specific conventions and integrates into the OS environment?
Ever built an user-experience atop ideas like "form follows function" and "don't make me think", that has beautiful design at the same time?
I actually question that there are more than a handful Web-UIs been built in that way, ever, IF actually any!
Yes. That's what I currently get paid to do.
> I mean with all that ARIA stuff, that really works for the blind or other disabled people?
Yes. If I didn't do that then we'd be sued by our customers for not being accessible.
> An accessible UI that honors the platform specific conventions and integrates into the OS environment?
Web-applications run in the browser, independent of the host OS. While web-applications do tend to adopt some OS conventions (such as having a "close popup" button in the top-left or top-right corner, web applications on-the-whole don't really ape after Windows or macOS' conventions and the past decade of post-Windows/post-macOS web-applications UX development shows that following desktop UI conventions really isn't necessary.
> Ever built an user-experience atop ideas like "form follows function" and "don't make me think", that has beautiful design at the same time?
Again, yes. (Beauty is subjective, of course - I've been told my work is "gorgeous" by my boss, so I've got at least one endorsement there)
> I actually question that there are more than a handful Web-UIs been built in that way, ever, IF actually any!
Fewer than I'd have liked, I admit. At least with today's "cleaner" look it's easier to visually design something that isn't an eyesore.
I appreciate a huge problem is that since the 2010s the learning-curve for front-end web-work has steepened considerably, and other barriers-to-entry have been introduced with no sign of them going away. Since the 2010s, when SPAs and modern CSS (flexbox, grid, responsive layout) came into being you might have noticed that fewer web dev clients today are making remarks like "my 12yo nephew could have made that!". Not to sound nostalgic, but in the late-1990s through the mid-2000s one could very easily be a very competent web-designer getting-by in Photoshop, Fireworks and Dreamweaver without ever needing to learn HTML and JavaScript (not that there was much to JavaScript back then either) - today it's increasingly essential to have at least an undergraduate CS degree to even understand how to correctly use React.js or Angular - and be comfortable with a command-line terminal. Project requirements for resolution-independent and form-factor-independent ("responsive design" - though I detest the term) web design means that the days of fixed-layout Photoshop-first web-design work and the age-old Image Slicing tool are over: tools originally designed for WYSIWYG print layout and graphic design are insufficiently expressive to allow someone to intuitively visually define how a CSS-driven layout and document-flow should work. In ye olden days it was straightforward for a relative beginner to grok how <table> could be used to make a semi-flexible layout - but explaining how CSS's grid's `auto-fit` works to the same person is impossible. And so on and so on.
Web-design has gone from the approachable place where COBOL was ("write business rules in plain-English!") to being a hallowed and exclusive techno-religious cult. I can't personally complain because I appreciate the job security I now have, but I am concerned it may lead to the web becoming less and less accessible to independent self-publishers who instead flock to much easier-to-use, but proprietary, walled-gardens like Facebook pages - or to web platforms that hide the complexity entirely, like Wix, and SquareSpace.
Meanwhile, beauty is in the eye of the beholder. The modern webtech trends are offensive to my eyes - in addition to being ridiculously compute- and visual-space-inefficient.
If you’re referring to the oft discussed “information density” issue, my goodness, scroll a little. That spacing is good for usability and, yes, accessibility. Those larger action targets and the space between them are not only good for us with vision impairment but for people whose only computing device is a phone.
That's an anti-solution. Scrolling is bad for your brain and reduces comprehension - it makes it harder for your brain to figure out what's going on.
There's a continuum between "everything on the screen is 6pt text with no spacing" and gigantic mobile-UI buttons on a desktop environment - and modern webdev errs far too close to the latter.
> That spacing is good [...] accessibility.
Big buttons with small text and no borders - which are part of the design trend - are significantly worse for accessibility.
> That spacing is good for usability
Spacing in general? Yes. The ridiculous amounts of spacing that modern webdev encourages? Absolutely not. There are diminishing returns, and modern webdev goes from "reasonable" into "unreasonable" territory.
> Those larger action targets and the space between them are not only good for us with vision impairment but for people whose only computing device is a phone.
My argument had to do with desktop platforms. You can build websites that are usable on phones while being efficient on desktops, either by building two separate sites, or through responsive design - but modern webdev doesn't, instead choosing to build desktop sites that have all of the aforementioned problems for no good technical reason.
> There's a continuum between "everything on the screen is 6pt text with no spacing" and gigantic mobile-UI buttons on a desktop environment - and modern webdev errs far too close to the latter.
This is probably not out of laziness or lack of consideration, but because pixel accurate pointing devices also better serve a wider range of desktop users when there’s larger targets. If you’re upset by this, you’re better off focusing on improving vision correction and motor skills than complaining about designs that accommodate more people than just you.
> Big buttons with small text and no borders - which are part of the design trend - are significantly worse for accessibility.
I disagree with your interpretation of the design trend. What I see is buttons with text consistently sized, and with padding fitting to the container to halve the cumulative padding while providing the same tappable area.
> Spacing in general? Yes. The ridiculous amounts of spacing that modern webdev encourages? Absolutely not. There are diminishing returns, and modern webdev goes from "reasonable" into "unreasonable" territory.
This is apparently entirely a matter of experience and opinion. But I do the majority of my web browsing on my phone except when I’m doing dev, and I feel exactly the opposite. Stuff is too crammed in. When I do browse on my computer I don’t see more spacing, just larger sizes of everything.
> My argument had to do with desktop platforms. You can build websites that are usable on phones while being efficient on desktops, either by building two separate sites, or through responsive design - but modern webdev doesn't, instead choosing to build desktop sites that have all of the aforementioned problems for no good technical reason.
What you’re describing is the baseline principle of responsive design. It should be available on every device. If you’re using a touch interface on a tablet, no one can know for sure you’re not on a desktop. So, big touch targets are still necessary for those users.
1. Asking people to show a little empathy to others (eg use your scroll wheel so people can benefit from reading a thing or clicking it at all)
2. Asking people to show a little empathy to others (eg recognizing that people who have violent ideologies are dangerous and don’t deserve free mandatory amplification from others’ resources).
3. Asking people to show a little empathy to others (eg not trashing people’s fun/exploratory/educational/hobby projects).
I don’t get downvoted for anything else. I’m sometimes surprised for the silly stuff I get upvoted for. But give half a damn and it’s just like the hateful crowds on Slashdot and 4chan and every platform they’ve flocked to, who just hate seeing anyone give a fuck about anyone or anything.
Bring on the downvotes!
It reads like you had a bone to pick with the information density argument, and just wanted to get into a flamewar when you saw someone who perhaps disagreed with you. I expect people weren't downvoting empathy. I think they were down voting a rude attempt at starting an off-topic flame war.
I use my tablet occasionally for Numbers, but it never even occurs to me to try it on my phone.
Visual Studio (even back when it was called Visual Interdev) supported first-class script debugging with Internet Explorer going as far back as Internet Explorer 4. Ditto cscript/wscript.
It just wasn't popular (and few people knew about it) because most people doing front-end web-work _back then_ weren't using Visual Studio, and in general most people weren't doing back-end web-work in Visual Studio either because (pre-ASP.NET MVC), ASP.NET WebForms is, was, and ever-shall-be, godawful.
If I wanted to have a editable table (datagrid) control it literally took about 20 minutes and I had something working and people could use it.
The problem with it (much like Angular which btw is basically webforms for JavaScript) is that it required you learning how the event lifecycle worked properly. Whereas other things at the time were web scripts and you could just hack against.
It of course had a lot of problems (like everything on the web at the time) but for what it was actually intended for, it was actually really good.
Other complaints about WebForms weren’t inherent to its architecture and should have been corrected early on, such as the lack of testability and over-use of [ThreadLocal] storage, and the nigh-impossibility of running WebForms outside of IIS, but these were never properly addressed by Microsoft, instead we had ugly band-aids like “BaseHttpRequest” and “HttpRequestWrapper”. Le sigh.
While the HTML is awful in earlier versions was IME of no concern. Most intranet apps just need to be functional not slick. I am sure it served different HTML based on the user-agent but I could be mis-remembering now as it was well over 15 years ago.
The lack of being able to run it on anything other than IIS isn't a concern. Most places using WebForms were Microsoft shops and whatever your opinion of IIS and Windows server maybe they weren't going to be running their ASP.NET app on a Linux server.
Most of the problems I've encountered was when people tried getting around the framework itself and rebuilding what already worked quite well within the framework (many people used to use large string builder objects in the code behind files in the page load event rather than using Web Components and building their custom HTML in there, I suspect it was because they didn't understand the Page/Component lifecycle).
I'm actually trying to get away from using .NET entirely (I am bored of the language, the frameworks and most importantly I don't like working with the developers who can't do anything outside of Visual Studio to save their life). But I do think the framework get unfairly maligned because of the quality of programmers that were using it. It is the same with VB.NET, the language isn't the best but the RAD aspect of it hasn't been bettered by anything IME.
It did - but the "different HTML" you refer to was HTML4 for IE5.5+ or HTML3 to browsers it didn't recognize. Even by 2001 that was a bad idea, and by 2004 Firefox was leagues ahead of IE6's support for HTML and CSS features yet ASP.NET WebForms defaults to rendering HTML3-era HTML to Firefox.
...and don't forget all of the problems inherent in user-agent sniffing. Users with too many third-party IE toolbars or shovelware on their computers would see things break (because said third-party software would frequently alter IE's default user-agent string to add their own product-names, which broke things).
> The lack of being able to run it on anything other than IIS isn't a concern
It was a *huge* concern because it meant that web-application code could not be run by automated testing tools! That was one of the design-objectives when OWIN was introduced: for greater testability (for unit and integration testing). Otherwise the only way to test WebForms applications was by having a dedicated web-testing farm with web-browsers open on the desktop driven by custom-written automation tools - that just wasn't an option for smaller shops. And Visual Studio didn't add built-in unit testing support until 2005 (only for Enterprise edition), and 2008 (or 2010?) for everybody else.
Another problem was that in the days of WebForms 1.x (before .NET 2.0) the only way to run ASP.NET applications, even for development, was by having IIS installed - but IIS was not available for Windows XP Home Edition (ASP.NET 2.0 introduced the "Cassini" local development web-server, but it was severely lacking and did not faithfully recreate the IIS environment, and IIS Express wasn't introduced until around 2008). People doing hobbyist development at home had to either pay to upgrade to Windows XP Professional (to use the rather limited IIS "5.1") or apply a variety of crude registry hacks to trick the Windows 2000-era IIS 5.0 to run on Windows XP Home Edition.
> Most of the problems I've encountered was when people tried getting around the framework itself and rebuilding what already worked quite well within the framework
What works "quite well" is subjective. ViewState just doesn't scale and is unsuitable for public Internet websites because it balloons the rendered page-size (e.g. if you have an <asp:DataGrid>, used as-directed such that it's only loaded on the initial page laod) then the entire data-grid's data is persisted in ViewState, which practically quadruples your rendered page-size (due to all the hidden control state) - which was unacceptable in the days when 56K modem use was still widespread (even through to ~2006+). Disabling ViewState was essential for any public web-pages, which increased the amount of work required to get things to _just work_. I could go on...
Intranet sites were run on highly locked down machines that were running IE. Don't pretend everyone was running their own browser on their machine. As I said it was intended for intranet sites, all the documentation and all the examples at the time clearly showed these user cases.
> ...and don't forget all of the problems inherent in user-agent sniffing. Users with too many third-party IE toolbars or shovelware on their computers would see things break (because said third-party software would frequently alter IE's default user-agent string to add their own product-names, which broke things).
So they were running third party things and it broke something else that had no knowledge of them. If someone runs hundreds of chrome extensions and it breaks my site, I wouldn't bother supporting them either. The situation isn't any different.
> It was a huge concern because it meant that web-application code could not be run by automated testing tools! That was one of the design-objectives when OWIN was introduced: for greater testability (for unit and integration testing). Otherwise the only way to test WebForms applications was by having a dedicated web-testing farm with web-browsers open on the desktop driven by custom-written automation tools - that just wasn't an option for smaller shops. And Visual Studio didn't add built-in unit testing support until 2005 (only for Enterprise edition), and 2008 (or 2010?) for everybody else.
Almost none of the shops were doing automated testing at the time. People barely do it now in the .NET space.
>Another problem was that in the days of WebForms 1.x (before .NET 2.0) the only way to run ASP.NET applications, even for development, was by having IIS installed - but IIS was not available for Windows XP Home Edition (ASP.NET 2.0 introduced the "Cassini" local development web-server, but it was severely lacking and did not faithfully recreate the IIS environment, and IIS Express wasn't introduced until around 2008). People doing hobbyist development at home had to either pay to upgrade to Windows XP Professional (to use the rather limited IIS "5.1") or apply a variety of crude registry hacks to trick the Windows 2000-era IIS 5.0 to run on Windows XP Home Edition.
So on an operating system that was intended for consumer use, they couldn't use advanced stuff like IIS that the home user wouldn't have any use for? Seriously?
> What works "quite well" is subjective. ViewState just doesn't scale and is unsuitable for public Internet websites because it balloons the rendered page-size (e.g. if you have an <asp:DataGrid>, used as-directed such that it's only loaded on the initial page laod) then the entire data-grid's data is persisted in ViewState, which practically quadruples your rendered page-size (due to all the hidden control state) - which was unacceptable in the days when 56K modem use was still widespread (even through to ~2006+). Disabling ViewState was essential for any public web-pages, which increased the amount of work required to get things to _just work_. I could go on...
None of this was intended for sites on the internet. I was specifically talking about the RAD tooling. Yet you seem to be talking about things it was never intended to do at the time.
I’ll add that to the other valid reasons that you mention.
Support for CSS "debugging" was completely absent, yes.
JS ignores the value of every statement in a comma-separated expression except the last one. So you can do trash like this:
const foo = (bar) => (
console.log(bar),
someComputationOf(bar)
);
I take stackoverflow and blogs for granted.
I did have a hand-rolled blog back then (The Hole Report) but was busy writing about magic tournaments and didn’t think anyone else cared about javascript hacks.
Fortunately another bad feature of IE was to alert() the errors, so customers were aware of each of them and could easily send us the bug back...
This bank employee used PrintScreen to print the screenshot on paper. He the successfully faxed it to his email, zipped it and uploaded it to our bugtracker. I had the zip of a .tiff of a scan of a printed screen. I still wonder whether he did it because he was upset, or whether it was a usual workflow.
I worked at Amazon during this time on our custom web server and before that I had been using telnet to hand type my commands or various perl scripts I wrote to emulate a browser's requests. And... ugh, tcpdump to figure out what exactly browsers were sending before they got to apache.
Firebug was like magic!
It's still really good!
To be clear I mean that Visual Studio had a C/C++ debugger but outside of that most languages that I used in any other situation were missing good debuggers.
1. The "hidden" element at the root of the IE DOM tree, only accessible with "*" via CSS
2. inline-block was broken on IE6 (but fixable with hacks), and no transparent PNG support.
3. The outline CS property was implemented the same as background in IE
Best of all was the dog slow IE 6 JavaScript interpreter, which was like 50x slower than Firefox and IE 7+.
TBH I found cross platform development during that time easier than when smart mobile phones came out. There was about 20-30 slightly incompatible forks of the Android Browser/Webkit and the processors were slow and everything was JS. Blackberry OS was still a thing. I also don't miss the problems with iPhone 3GS and 3D background layer flickering.
Also programming cross platform at the time showed me how to write lightening fast JS. That has made me a lot of money when people come to me to fix their crap web apps.
It was a DXImageTransform Alpha filter. Complete pain to use.
In the recesses of my brain somewhere is a memory that it was related to ActiveX, and/or the CSS filter property. You set some special filter value that invoked ActiveX? Maybe I'm remembering incorrectly but if I think about it too deeply I might start screaming and never stop.
I don’t miss those days.
Now you can "copy URL" or "copy URL parameters" but there's no way to copy them all in one go. You need to manually combine them in an external text editor which is annoying.
Have been a professional developer since 1999 - no idead what you're talking about.
So not a very good example at all, in fact quite the opposite, it just happened to ride the back of the anti-M$ wave and wasn't at all innovative, copying its features from already existing products.
Conversely, though it was free, IEDevToolbar was only really advertised to MSDN subscribers, so never got much penetration, especially as by then everyone hated IE6 and a lot of Devs worked in Firefox first.
But my company only supported IE6, and when we finally started supporting Firefox, firebug was an annoyingly sub-par experience when debugging js.
Even Chrome's early Dev tools had some sorely missed features when it first came out, as far as I can remember it took them years to support being able to just hold your mouse over a variable and see its value. And because it was a web-page about a web-page you got all these weird bugs. And the CSS editor was (and still is) super annoying with its attempts to cut up your text.
On top of that visual studio also had a JavaScript debugger, I'm sure there were plenty more paid tools you simply didn't know about.
<https://web.archive.org/web/20051223164847/https://www.mozil...>
<https://web.archive.org/web/20050206082145/http://www.mozill...>
<https://web.archive.org/web/20050206185242/http://www.mozill...>
(Joe Hewitt created DOM Inspector and checked it in to CVS while working at Netscape. Robert Ginda had separately created Venkman. Firebug used the XPCOM interfaces that had been created to allow for Venkman's debugging capabilities, but IMO was always inferior to the much more powerful Venkman, even if Firebug was slightly prettier to look at. PS: shame on Mozilla for breaking those links. Do you even know how to Web?)
> Firebug came out AFTER IEDevToolbar
I'm not sure that even if you focus purely on Firebug and ignore DOM Inspector and Venkman that this is even true. Do you have a source for that?
Absolutely not.
> Firebug wasn't just prettier; it was much more usable
Venkman made some debatable decisions about UI defaults, as is the case with a lot of tools built by old school programmers trying to solve their own problems, but it was more customizable, flexible, and powerful (as is the case with a lot of tools built by old school programmers...). Aside from Firebug's template-based rich console, every feature implemented in Firebug's debug pane was implemented in Venkman, except Venkman gave you even more latitude and control. Firebug's debug pane was a basic UI over a subset of Venkman's APIs, after all, as previously mentioned. It was only many years later (much closer to Firebug's death than its birth) that Firebug got some improvements like showing a variable's value in the source window while stopped at a breakpoint without having to type it into the console (or set a watch on it, or look at its activation record entry). Venkman never had that, but it pales in comparison to all the things that Venkman could do that Firebug did not.
Firebug made its own share of dumb decisions, and the degree of dumb in those instances was higher.
> [Firebug] focused on actual website code
I'm not sure how it could be "focused on actual website code". Venkman was a straightforward JS debugger. (The only way this could possibly make sense is if you're referring to all the stuff baked into Firebug outside it's debug pane—style sheets, live view of document nodes, cookies, and so on; all things outside the purview of a language debugger—in which case it becomes an apples and oranges comparison. It would make more sense to criticize DOM Inspector for any of those things than Venkman. And once again—there were plenty of dumb decisions by Firebug in that comparison is concerned.)
Yes, you're focusing on the debugger only. The fact is, most people simply did not use Venkman since it was hard to understand how to use it, for what context it was meant. Firebug tied the debugger into a wider context, making it more accessible, and reached a level of popularity that Venkman never had.
> a level of popularity that Venkman never had
You're not saying anything I don't already know.
It may very well have been the case for a small number of MS centric devs, but for the large majority of users, it was Firebug that really changed the game for the bulk of Frontend devs back then.
While I agree that IE's devtools had more features regarding xpath integration, you'll also had the problem that it was based on libxml (yes, the reason trident was exploitable for decades, and probably still is).
IE's devtools didn't have access to the DOM and only had access to the HTML/SGML/actually XML representation _before_ it was parsed into the DOM.
This gave you hundreds of error scenarios where debugging user events was simply impossible if they caused the DOM to change, something like adding a node or debugging a parentNode was impossible in trident.
And oh how often have I seen bugs in websites that were relying on specified flow roots that behaved differently in trident. Something like an unclosed <p> in the wrong place could easily mess up everything in trident and switch it to quirks mode.
Remember IE was exploitable via a parentNode.remove(parentNode), too? The hooks for devtools was the underlying reason.
I am not sure why you claim that IE had superior devtools experience. You must have done a lot of ActiveX related development, because everything else was impossible to debug in my opinion.
The best thing MS did was to create the Edge team that tried to refactor trident, and soon realized that it's impossible and instead started over from scratch.
Every developer from around 2006-2008 knows what I'm talking about. Debugging JS in IE6 was like trying to build a house blindfolded with both arms tied behind your back. Firebug is when JS went from just a web augmentation toy that could silently fail and your web page would still mostly function to becoming a critical function for a web page (many will see this as all a big mistake).