I'm still looking for "just use links". So many frontends I see use fancy onclicks to emulate links (including updating window.location). However they are either not links or are void links. This breaks all sorts of useful things (copy link location, open in new tab &c.).
Breaking it is completely unnecessary too, even with single page apps.
It's not all that hard to build a React or Angular apps that use proper links along with the browser history API. Designed properly, the apps should be able to load their state and render correctly even when deep-linked to somewhere other than the app's top level.
This isn't a new concern - I remember paying attention to this back in the old days of SPAs using GWT back in 2009/2010.
Unfortunately, many web apps choose to ignore this. On the bright side, lots of them get it right, too.
It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. The closest thing to an exception being cases where one needs to be logged in to see a page, or when links are consciously invalidated for some other reason. And even then the website/webapp should still just signal this to the user without a bazillion redirects.
The problem there is the slide show. Converting a series of slides to a page in traditional vertical scrolling format works just fine. Overriding the back button behavior is just expecting a second wrong to make a right.
Your example is exactly why we have both History.pushState and History.replaceState[0]. The core question there is whether a new slide represents a new page or not. And in this case, I agree that it doesn't: it's the same page, just in a different state.
EDIT: If you mean one of those 20-image slideshows intentionally made to create fake click statistics, I agree that that's absolutely infuriating. But in that case ergothus' comment applies: the real problem is bad faith webdesign in that case.
And this example pretty much nails the theme: there is no technical reason for these problems. If a website screws it up, it's just bad design at this point.
But the problem there is that they used a carousel in the first place. Were it content that justified clicking 30 times into it, it would also justify backing out of it 30 times.
For something like a slideshow, I think you could have it both ways - default to a scroll view that shows all of the slides at once, and make it so clicking a slide shows the slide on a single page that is deep-linkable. The user could then navigate forward and backward between each individual slide page if they so desire.
I suppose it's all a matter of trying to do what will best match user expectations. Or just whatever will make them happiest. Maybe call it the principle of least annoyance.
Of course, if you make an ad supported slideshow app, maybe you want to show one slide per page to get more ad impressions. I suppose that would be the principle of maximum revenue, along with its corollary (from the user's perspective): the principle of maximum indignation.
The problem is that it might take a half-dozen clicks to realize it's not worth reading the other 24, then you need to click back a half-dozen times (worse if there are page reloads during that).
Or, use another built-in feature of the browser's back button. Click-and-hold the back button so that you can see a contextual menu with the steps you can go back to quickly. If I click back more than twice, the third is a click-and-hold.
That's my point though - if it takes a half-dozen clicks to decide it's not worth it, then they weren't using a good format anyway. You likely did the last 5 clicks hoping things would be different after the click - the click itself was NOT a value add.
I'm not saying it isn't useful to bypass that to get back, but then you're literally asking the people that made the bad design decision in the first place to make the good one to let you out - and they likely won't, for the same reasons they gave you that UI in the first place.
> It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design.
What if state should be destroyed when you press the back button? What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page.
Should clicking the back button return me to a page containing the image? A page containing 'this image has been deleted'? The website I was on before I was on the photo app?
Which actions defines a history-worthy state change? Should clicking around a menu generate 10 history events? What about toggling a checkbox? What about an action that changes most of the information on a page? Should that generate a history event? What if that action is bringing an in-app tab to the forefront?
What if there is an obvious history event that should be generated, but there is no good reason for why a user would want to go back to that state?
It doesn't even matter how you answer all of the above questions - other people will have different answers for them, and have different expectations for how the back button should work, on the same app.
Not being able to click "back" out of a POST isn't broken, in my opinion.
Basically, if the "back" button behaves differently than it would have behaved in a functionally similar web app in 1998, it's broken. Web apps in 1998 didn't let you click "back" out of a POST.
In 1998, wouldn't a well done POST have issued a 3xx redirect? in which case, going ba k would bring you back to the form or originating page, right through the POST. In which case, the browser may still show the now-deleted image until the user explicitly decides to refresh the page. IIRC the old Opera browser was good about this, to the point of remembering dynamic DOM content as it was.
How will someone on a laptop run my website as an 'app'?
Should I download a Wells Fargo app to my desktop, so that I can do banking with them? And a Google Docs app? And a Seattle City Lights app? Maybe a Progressive app, so I can manage my insurance policy? And one for the Washington DMV?
How many problems is running random binaries from random developers at those organizations going to give me? How much more expensive is it to develop apps, over websites? How will you make these apps run on Android, IOS, Linux, MacOS, and Windows? [1]
All of these websites have rich app-like functionality. The web was designed as a document store, yes. This is 2018, though - its not used as a document store. It's the place where I do my banking, my shopping, keep my spreadsheets, and make image macros. Turning all of that into non-web apps will just make development more expensive, degrade my user experience, and negatively impact my PC's security.
But hey, the upshot is that the sanctity of the back button will be protected!
[1] Maybe we could sandbox them... And have a cross-platform 'operating system'[2] where they can run. Maybe even have several such 'operating systems', with similar functionality, but built by different vendors. Vendors like Microsoft, Apple, Mozilla, and Google, maybe?
[2] We can even make this 'operating system' support opening static .HTML pages, so that we can 'browse' through them.
> Which actions defines a history-worthy state change? Should clicking around a menu generate 10 history events? What about toggling a checkbox? What about an action that changes most of the information on a page? Should that generate a history event? What if that action is bringing an in-app tab to the forefront? What if there is an obvious history event that should be generated, but there is no good reason for why a user would want to go back to that state?
These are great questions, but they kind of apply to a different level of the design than my litmus test.
Start with not making it more complicated than it is: browser history is browser state that we should be able to go back to. When this is not the case, it does not go into browser history (strictly speaking about using the JavaScript history API here).
Otherwise, we need to ask and answer questions like the one you posed. And at that point, "does this break the back button?" is a good first question to ask oneself to ensure we think things through and figure out what it is that we are really trying to achieve.
> What if state should be destroyed when you press the back button?
That says something about which state of the current page is going to be stored in the history, not which state of the previous previous pages has been stored.
> What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page.
This is a solved problem! The "deletion successful" message should not be its own page to begin with, that's what makes it look more complicated! A modal pop-up is the right answer here. (tangent: I'm sure we both agree that many problems are caused by trying to fix issues created by using the wrong initial solution)
If all of this happens within a photo app, the app is the page, which we never left; we clicked a button, not a link. App state history is not the same as browsing history, so if, and only if, we want to preserve snapshots of the photo app state, we use replaceState and/or pushState.
In the case where different pages are warranted, for example within a photo gallery on Facebook or Imgur, the pop-up still happens on the page linking to the uploaded-but-now-deleted photo, followed by a redirect to, say, the main gallery. The link to the uploaded photo should then become a 404 page, because it is now an invalid link.
In both cases, the "deletion successful" modal obviously does not need to be preserved in the browser history.
> It doesn't even matter how you answer all of the above questions - other people will have different answers for them, and have different expectations for how the back button should work, on the same app.
And some of those answers will be right, most will be wrong, and some will depend on the desired context. But presenting hypothetical exceptional cases does not prove there is no such thing as really obviously bad design. There are exceptions, but they are just that: exceptions. They don't invalidate the question as a good first guiding principle to start from.
If anything, doing provokes these questions: you came up with them in response to the implied question "what does it mean to break the back button?" That is a lot better than just slapping something together without thinking about it.
> Start with not making it more complicated than it is: browser history is browser state that we should be able to go back to. When this is not the case, it does not go into browser history (strictly speaking about using the JavaScript history API here).
What is the state that we can go back to?
Is it the part of the app that we were on, or is it the part of the app + the content? Content these days is dynamic - if its gone, can we really 'go back to' it?
> This is a solved problem! The "deletion successful" message should not be its own page to begin with, that's what makes it look more complicated! A modal pop-up is the right answer here. (tangent: I'm sure we both agree that many problems are caused by trying to fix issues created by using the wrong initial solution)
That's not what's important, though. If 'deletion successful' is not its own page, then imagine that I then navigated to some other part of the app after deleting the image. What should happen when I press the back button?
a) Go to the "Do you want to delete this image" screen.
b) Go to a "No image found" screen.
c) ???
Option a) is misleading, because the image has already been deleted. Option b) is abuse of the back button, because we have not returned to old state.
> In the case where different pages are warranted, for example within a photo gallery on Facebook or Imgur, the pop-up still happens on the page linking to the uploaded-but-now-deleted photo, followed by a redirect to, say, the main gallery. The link to the uploaded photo should then become a 404 page, because it is now an invalid link.
When I click the back button in my browser, I see a cached version of the webpage I previously visited. What you described is not the behaviour I expect, (and is another way of breaking the back button).
> And some of those answers will be right, most will be wrong, and some will depend on the desired context. But presenting hypothetical exceptional cases does not prove there is no such thing as really obviously bad design. There are exceptions, but they are just that: exceptions. They don't invalidate the question as a good first guiding principle to start from.
These aren't edge cases and exceptions. This is trying to shoehorn a leaky abstraction (the browser back button) into a paradigm where it is often inappropriate, surprising, or just plain unworkable (pretty much everything you do in rich webapps). Your operating system doesn't have a 'back' button for that very same reason.
If your app has a consistent (Internally, and with how the rest of the web works) definition of what going 'back' is, great. Implement it. If it doesn't, that's also fine. 'The back button doesn't work in your app' is not, in itself, a sufficient heuristic for a poor design.
Virtually every site breaks the back button now. Even reddit will suddenly forget discussions I had closed, and where I was on the page, and then have to reload something, when I all I need it to do was take me back to the same state on the page that I had before.
I was including "fail to return to page state at time link was followed" as "breaking the back button". Reddit, Quora, and sites using Disqus fail that.
All those cases where pressing back repeatedly doesn't actually go back? They're broken. We may not be able to define 'broken' perfectly, nor catch every case, but we can definitely spot the worst!
Unless you mash the back button really quickly ...<sigh>
Your back button is "broken" every time your last transition from the previous page to the current page changed information on the server, and that information change isn't reflected in the cached version of the previous page your browser helpfully shows you when you hit back.
Cache invalidation is a technical solution, and it could conceivably be done with header magic or something, but the real problem is people thinking the back button undoes history and the server (and, possibly, reality) disagreeing.
Going "back" and showing the old information is accurate. I'm not reloading the prior URL. I'm viewing the last page I looked at. In fact maybe I don't even have network access at the moment (on a subway). I can always opt in to reload the page if I want to see refreshed data.
> if it breaks the back button of the browser, it's the wrong design.
Some people don't care about a back button in a single page application and it isn't "trivial" to implement properly. It requires libraries, polyfill support, etc. And in a world where everyone is complaining about js bloat, it should be no surprise why it exists.
As I recall when learning angular (2) and react (whatever 2016 version was), almost every tutorial on the subject of routers would just go "the easy route" that inevitably avoided using the browser history API.
I haven't checked in a while, I wonder if this situation improved? A lot of these frameworks market themselves as dead easy, but I always found a gap between the "dead easy start-up" documentation, and the documentation that essentially amounted to "read the source code."
By the same token, why reinvent things like scrolling, break the back button, or throw font sizes so small at your readers that they need to zoom to read? (To say nothing about top and bottom bars that follow you around on your 13" laptop screen.)
Humble suggestion: design fads.
My own question would be whether this gets taught anywhere. Because if it does, a few someones need to get fired.
> throw font sizes so small at your readers that they need to zoom to read
My problem is usually the opposite: I constantly stumble upon websites that use ridiculously large fonts like I'm a grandma that tries to read something on an overkillishly-retina display from meters away. However it doesn't usually bother me when I'm browsing from my desktop 'cause I have options to zoom out; however most of mobile layouts feature something like <meta name="viewport" content="..., minimum-scale=1"> (edit: also mentioned in the article albeit in a bit different context), which makes me choose between intensive vertical scrolling in regular mode and constant horizontal scrolling if I "request desktop site". (Yeah, I know, "reader mode"; it's a reasonable hack but I'm not quite satisfied with any of implementations either, and it only works for whatever browser thinks the main body of the page is.)
Most web devs I know are self taught. That includes the computer science majors scoring jobs at Google and Facebook - I haven't heard of anybody getting an "education" in web development, outside the bootcamps, and as a bootcamp attendee I recall us focusing on just learning how to program over anything else. Like, there wasn't a web design sprint.
Is this everyone else's experience? How has web design been taught lately?
One reason is that if you have a link, that link will be copied and sent. Then when the receiver clicks on it, the user has an expectation that they will see the same thing as the person that sent it. For the developer that means you have to recreate the state of the app, from the link. This further means that the link must contain all necessary data to do that and the developer has to write more code to recreate the state (sort order of a column in a table f.e.)
There are two choices: don't recreate the state -> people will call each other stupid over the phone because they see different things for the same link,
-or-
Recreate the state -> more money, more time,
-or-
Just don't have links at all. Which is what people usually choose because is faster and cheaper.
What changed was that before, "to do the right thing", i.e. have real links, was the easiest and the cheapest. Now to do the same, you need real developers. Even in Angular there is/was a discussion of where to put the state of the app in the url? put it in the path part of in the hash part? the difference being that the hash is not sent to server. So for search engines all those links are just one actually... Which is ironic because Angular is made by a search engine.
My guess is somebody over-engineered a "make anything into a link" helper function and then decided it was easier to just use it everywhere, rather than preferring <a> tags in the 90% of cases where it would make more sense.
How do screen readers handle these script-based links? I don't mind it from a "I have working eyes and arms" perspective, but I imagine it's kind of a pain for assisted vision?
I think some of it is possibly just ignorance, too. For example, I've worked with a fair bit of code full of `<a onclick='...'>` tags, where the click handler basically invoked the router and redirected to a new page. Seems to happen a lot in React/JSX code.
I've done that before, when I was noobish and couldn't get the damn framework to work like I thought the internet worked.
There was this hellish twilight area of my learning web dev where I was transitioning from how i thought the internet worked (HTML pages with anchor tags) to how it actually worked in 2015, which is slapped together framework routers that I couldn't fenangle to work with the History API.
> I've no idea what people expect right clicking a delete link to open in a new tab to do?
I expect it to issue the delete, and then dump the response to the delete into a new tab rather than navigating away from the page that hosts the delete link.
There might be ten other delete links on the original page, and I don't want to delete-back-delete-back-delete-back, when I can just open all of them in a new tab, then go through the tabs to look for errors.
That sounds like the right behaviour to me, although there is an arguably nasty non-idempotence. Click it the first time and you get a DELETE response. Click it the second time and you get a 404.
Yes, but application developers have long faked it using GET .../thing?op=DELETE
When you get sick of faking it you look into why there is no way to get browser to send real DELETEs and PUTs and w3c verbiage says "because application developers don't seem to need it" ... because they fake it ... because they have to fake it ... because browser don't do it ... because devs don't need it ...
I was gonna write a snarky comment about using a <button formmethod="DELETE"> but apparently, the only methods allowed on a <form>s and <button>s are GET and POST.
I wonder why these limitations. Especially since you can get past this with an:
Though as dragonwriter points out, using a button+POST to fake a delete is much better than using a link.
Api-wise that's a reason to mux your puts and deletes in the POST handler and not in the GET handler, since it force the HTML to use buttons rather than links that might get crawled.
I don't care about minor cases like that. I'm talking about things like a CMS not letting you open a post in a new tab because they wanted to load the post via Ajax and failed to provide a fallback.
Really egregious examples even change the location so that I can copy the URL after clicking, new tab, paste, and hit back in the original, but I can't middle click for a new tab.
I agree for cases where the text is supposed to behave like a hyperlink - it should be one.
But in cases where its behaviour is that of a button (even a button which has the appearance of blue text - think iOS) then onclick is a good choice. Especially for contexts where “open in new tab” makes no sense.
I can’t see any valid reason for using a void link - worst of both worlds?
I recall reading a story about someone who had implemented some sort of table using links for actions. At some point the app data mysteriously got wiped out. Turned out a user had Alexa toolbar installed and it crawled the "delete" links on each row (as well as all the pagination links)...
This is what happens when you use a HTTP GET to perform an "unsafe" action. HTTP GET links should always be safe to crawl... Always... It's in the spec for a reason.
Seen people make mistakes like this before... Even using a POST when it should be a GET can cause funny behavior. Funny, but not dangerous behavior like using GET instead of POST.
Whenever I bring a new web dev aboard this is my first lesson to them, and I say "all sorts of clients are going to crawl your webapp, so make sure your webapp is coded correctly for it." Browsers are coded with this assumption, bots/crawlers, email clients, etc...
Also, junior devs don't use HTTP error codes and it always ends up biting them at some point. A 200 response with a body that says "server error" isn't going to bubble up through your JS properly.
The web server had a deficiency where it modified data on HTTP GET requests. We could probably agree that navigation should be links and other actions should be buttons. Visual appearance of such should probably be left alone, but is technically a decision that can be made independently.
Oh, people can abuse anything. Maybe they want their CSS all in-line at the top of the dynamic HTML. So they run the preprocessor during page generation on the server.
Use a separate CSS via link tag? Oh no, I heard that was slow. Set expires cache header for 1 day? Oh no, that makes testing hard for me and what if the CSS changes?
Web developers sometimes use the dumbest reasons to avoid doing good things.
I read it as using 50ms of CPU and it didn't say where. Using an extra 50 ms of server CPU happens all the time in my experience and no one seems to think this is a problem.
At least not until they try to solve the C10K problem or survive the "Slashdot Effect." That's when people discover that static pages are king.
More likely, they're completely oblivious to the impact their changes are making, and they're just looking to "make it work" on their computer for that one page load a minute.
Yes we remember how limited was the web back then. I also miss those times, good memories. But to make money out of it we had to follow the latest trends in UX since they attracted more visitors than us. The first DHTML, the java applets, the arrive of flash, and then XHTMLHttpRequest used by google in their new born gmail. So now we are here with these new awesome technologies and we want to go back. But I’m not sure it will be fun.
And extensions like Vimium/pentadactyl/VimFX that let you do all your browsing from the keyboard without a mouse, and which therefore have to be able to detect and send a signal to follow links.
a good developer would do a simple *ngIf and do a toggle on either using <a href=...> or <my-fancy-button (click)="navToPage()">. Call it "olde time mode".
Ironically, this article was posted on Medium, whose apps are notoriously inaccessible. Despite being a reading-focused app, it does not let you change the text size or spacing in any way. And on iOS, it also ignores the user's systemwide dynamic text setting.
I use plugin for that, it walks through all elements on page (createTreeWalker) and detect actual style position (getComputedStyle) and if it is "fixed" or "sticky" it changes display to "none". So far it worked with every bar, even "use app" button. Then as a bonus I remove all fonts, change color to black on white background, and turn full screen mode on.
It really annoys me when a site that just needs to display some text loads a whole react-redux framework.
When it comes to reading text I honestly prefer the old school academic websites (albeit with a max-width set).
Keeping stuff simple even makes maintaining the site simple, I personally run https://www.discoverdev.io and have used zero JavaScript. Inspired by brutalist design principles :)
My biggest pet peeve is when sites use js to try to "help" me scroll. What. The. Hell. is wrong with developers who think their users' browsers can't scroll? Am I the only one?
Often the blame will lie with someone else - the designer or the PM. Some webdevs are to blame, but many of us would prefer to work on tasks OTHER than arguing with the browser over how it should do it's job.
The most common source of blame for scrolljackers are wordpress template writers. There was a huge surge in developing them a few years ago that happen to coincide with popularity in scroll-jackers actually being considered good. Mostly because of the Windows crowd not actually having a great scrolling experience like Mac. Now windows scrolling is 95% on par with the mac, but alas, the scrolljacking stays with us until people migrate off wordpress or people are interested in developing for wordpress again.
Reading this article made me realize what it is that's broken about the concept of semantic markup and why websites even today are div soup.
It's the same reason why divs won in the first place. You can't dictate the shape of a document to people and it be anything other than a kludge.
Take the site I work on, Great Big Story[1]. We have sections and headers, but our content isn't defined by text, it's defined by graphics and videos, with little metadata sections on the video player page that I suppose could be semantic if we had the right descriptive tags. I use semantic markup when it seems to make sense, but we have so many weird little needs to introduce elements just for styling purposes.
Take a recent example, I need four elements to make a styled file input form. Two labels, one to look like a button and can be clicked, taking advantage of the browser behavior of treating clicks on the label to be clicks on the form. The other label is the actual label, could be just a span if I wanted, it doesn't have the htmlFor attribute set. The actual form input button is hidden using CSS tricks because the actual button can't be styled. Finally there's the filename display, which is set to the filename of whatever was uploaded or the existing one if present. This uses Javascript callbacks to get set.
None of these elements are semantic, legacy cruft keeps the markup from being simple and readable. I suppose you could demand our video presentation site to be a motherfucking website[2], but I fail to see how that will actually improve much of anything and would just hurt our brand. I'm getting a little tired of coder hatred for web fashion. It keeps us all employed.
But I think we're at least 10 years out from being able to actually use semantic markup. Web standards and browser vendors still have some maturing to do.
Well, it's a problem of mixing data and visual elements.
In a good model of the web, html is your data, css is your styling, and javascript doesn't really exist.
In another model of the web, your data would be your data, html/css would work together to form a scene-graph. Javascript defines the relationship between your data and it's scene graph.
That friction, are we using html as data or as part of our scene-graph, is what causes a lot of these problems.
Thanks for introducing me to the concept of the scene-graph.
I tried to make an argument on a React community slack that components are purely visual, that they should express the visual structure of the web page, in the context of an argument over how state and props should be used.
He hated the rise of the Redux ecosystem, and I was trying to make the point that if you don't manage global state in your application sanely, you'll only end up reinventing it poorly, passing onChange across the Atlantic in the case where your save button doesn't live in the same visual space as the rest of your form.
His response was to bring up the Router component to make the point that not all components are visual.
UIs are complicated things, I've found that the visual model is the best encapsulation concept. Components aren't bad, but you need to first have a need to use them, because there's definitely a tradeoff, and second you need to use the right abstraction techniques. Routing components are a hack, different pages should just load different base components in the site backend.
But it seems like once someone swallows the functional paradigmatic koolaid, they lose all perspective to see when the paradigm fails to produce erudite design.
The site you work on is blank if Javascript is turned off. I do not see anything in particular on the home page that should require Javascript to render.
You realize you don't need input field for file input in any of the modern browsers. Just capture the click event and create input field temporarily.
let i = document.createElement('input');
i.type = 'file';
// other attributes if you like
i.onselect = ev => {
// ev.files contains selected files
};
i.click();
i.remove();
No stupid styling hacks needed. At most you may need tabIndex on the <a> or <div> that represents the button for selecting files.
You can leave <input type=file> around if you want to submit data via <form> and not via XHR.
You clearly never implemented any of the above stupidity with file input styling and overlays and passthrough of events, and different unchangeable widths of file inputs you had to account for in various versions of browsers, and bugs in specific browser versions, and discontinuity in the input field clickable surface so part of the button is not clickable for no reason whatsoever to the user, so that everything works as expected in E6+IE7+IE8+IE9+FF1+Sfari,... to think it's even comparable on the hackiness scale.
That's another issue easily solved by DnD API modern browsers implement. And should probably be done differently with regards to UX depending on whether the clicky part was a button, or a larger upload area.
Frankly, I don't find the original UX of dragging files onto an upload button all that intuitive. So instead I add drop functionality to a larger container in my apps. So if I have dialog that accepts files, users can drag files anywhere over the dialog and the dialog highlights that it accepts drops while dragging.
The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?
Why does there even have to be a button? I want an API not a button...
> The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?
Why don't the buttons on your website look like HIG-compliant buttons on whatever platform the user is using? That's what web chrome looked like back in the aughts and it was fantastic. Apparently you can still do it: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Th....
Question, is the point of HIG-compliance to make everything look exactly the same on a platform? Or is it to nail down some abstract sense of what makes UI intuitive to use?
It seems like people with this viewpoint pay lip service to the latter goal, which allows for trends like Material Design so long as they fit with the guidelines, while really wanting the former, which to me looks like nothing more than tilting at windmills.
I'd post screenshots of our current CMS work, where we have a design staff working earnestly to make everything super-intuitive, but HN doesn't do image management so this discussion will be sadly deprived of examples.
> “The purpose of visual consistency is to construct a believable environment for users… The transfer of skills is one of the most important benefits of a consistent interface, especially for beginning users.” pg. 10
> “…consistency makes it easier for a user to learn new applications; it also makes it less likely that a user who follows habits learned from one application will make a disastrous mistake when using a different one.” pg. xi
The HIG goes beyond simply expressing principles of what makes for a good UI. The consistency in and of itself allows users to develop an intuition and muscle memory for how their computer will work. That intuition is destroyed when different apps look and behave differently. In that sense, it's better to be less intuitive according to some abstract principle if necessary to achieve consistency. It will take the user longer to understand a "more intuitive" UI starting from first principles than to understand a UI that exhibits the quirks embedded in the HIG they already know.
Yeah that looks like it's always going to be fighting an uphill battle when it comes to the web. Native apps, certainly. But without an order of magnitude more professionalization of the workforce such that they can fight against business and popular trends, we're stuck with what we have.
This will never work because each browser has its own idea of how native controls should be rendered, even within the same platform. The link you posted even has examples of this. I'm all for the idea of using OS-native controls where possible, and for native apps you should absolutely do this, but I just don't think it's feasible on the web; I believe making your controls consistent across browsers is a better goal in most cases, as long as you don't sacrifice accessibility.
Is that a problem with the file input button, or with every other button on your website?
The file input button does seem to be a barely remembered feature by browser builders. It's weirdly specific, doesn't work the same way on phones, and probably only hangs around because there isn't a decent alternative.
IIRC correctly, the File Input button was deliberately excluded from CSS styling, as it was felt that it would be abused to 'steal' data from clients, if the user wasn't aware it was file upload...
Just thought I'd let you know, Great Big Story is running a development build of react. You save some of bundle size and performance by switching to a production build.
We're replatforming for a redesign and so that should fix that, but thanks for the heads up. Just about all maintenance on the current site is on the back burner atm except for GDPR stuff.
What do you mean by "semantic" markup? The markup in the file upload widget you describe is rather generic (label, button, p or span, presumably div) but almost completely meaningful (caption, button text, file name, widget/drag and drop target), not a div soup; I don't see how you could improve it.
The whole debate between semantic markup and visual styling in CSS looks to me to be a massive exercise in people yelling past each other and needlessly making all life difficult.
I've ranted about this before, but worse is that everyone insists on trying to go with the default flow of elements as much as they can. Example I used last time was that it is actually easy to layout things and have them look pretty solid between browsers, iff you embrace absolute positioning. http://taeric.github.io/cube-permutations-1.html is a page where I played with laying out a Rubik's cube. I confess I have not tried it in all browsers, as I don't care too much, but it works in all of my browsers, including my phone. I shudder to think how I could have done that with just using floats and inline-block style concerns.
Why do I claim that makes it worse? Because you wind up with more markup just to trick the layout engine to calculate where to put things. Instead of you just figuring it out largely on your own and not building a Rube Goldberg machine to layout a page.
Internally for a previous company, I did this only to have the next person try to get rid of absolute positioning because "gross". Over two sprints later they caved and went back to the working solution that was a) less code, b) worked everywhere, and c) was easy to modify by virtue of a.
Works in all browsers, maybe, but certainly not all screen sizes. On my 1080p 5" nexus 5x, opening the page leaves me with unreadably small text. If I zoom in, the text doesn't reflow. So now I need to bounce scrolling around from side to side to read a line of text.
I suspect if I performed the same test in my 1440p 27" monitor, I'd have a surprisingly similar problem, of overly small text in a small box in the centre.
So in reality, while it may have made it super simple to preserve the shape of the Rubik's cube unfolded, it's impeded reading the main content on anything outside the range of a plus side phone to a Macbook's scaled 1440x900 canvas. And really the Rubik's cube could have been just a image (an SVG if you're worried about sharp or selectable text).
Ha! I should have said the technique works. I'd obviously want to lay things out a little smaller on phone screens. Though, for that particular use, is just punt and say not supported on smaller screens.
Note, I couldn't just do an image because of the animation nonsense I was playing with.
Edit: though, oddly, I think you are really complaining about some of the styling I inherited from org. I can possibly fix that easily enough. Never tried. Pretty sure I can just swap out a "width" with "max-width" and things will reflow as desired. For my eyes on my phone, the current width was fine. I didn't bother checking why it killed reflow. But I can confirm it reflows as desired on desktop if I do that.
Sure, max-width will restore reflow, but now your code listings and images break out of their container: https://i.imgur.com/utCVxg1.png
My point is that absolute positioning/pixel perfect designs are easy because they solve a simplified project "How to have my content look correct at a fixed size". But it breaks down once that fixed size is no longer reasonable for the target device.
Right, I agreed that what I did would not scale down to small screens. Nor will it work if you ever try and display on an apple watch or some such. The max-width would have just given you flowing text. I fully expect the visualization to be broken on small sizes.
I contend that is just not a requirement for most things. This particular endeavor mine, included.
So, what point are you arguing against? If it was that I pitched this strongly as a panacea. I definitely concede it is not one. But I also don't believe in panaceas.
If if it is that there is an easier way to get that layout such that I can play with it in silly animations without absolute positioning, I'm game to see it.
Edit: I should say thanks for getting me to look at my own site again in a long time. The code block would need the same width->max-width flip. Though, I question on why anyone would look at that page... well, ever, first. But in general even on a small screen. Not sure what I want code blocks to do there. Will take another look sometime hopefully this weekend. :)
Went ahead and flipped both of my "width" overrides to "max-width". Amusingly to me, the worst part of the pages, now, it seems is the MathJax stuff. That said, I'm not seeing an obvious difference in my mobile firefox, just chrome. Still not entirely sure how I would even want these to look there. If you have a good pointer for a site that styles code decently on mobile, I'd love to take a look and see about emulating/stealing.
I like absolute positioning but it's really hard to learn how to use fluently. New devs need to be educated on the concepts otherwise you get a total mess.
Flex and grid are more intuitive so they're easier for juniors to train up on.
How is it hard to learn. Put someone in front of some graph paper and let them layout what they want the page to look like. Get someone a little more experienced to help them pick the points that can grow, and off you go.
Not to say that they can't do better with flex and grid. But it was like our entire industry didn't even bother trying to learn with the first tools that our industry made.
I think the main difficulty is twofold. First there's the box model, which was different in IE than in the rest of the world for a long long time. Juniors that don't understand the difference will produce markup and styling that work in one browser but not the other. Absolute positioning is way more sensitive to the box model than other kinds of layout.
Second, unless you really want to insist on absolutely positioning everything, you're just going to need elements to flow occasionally. Most devs just aren't going to get a granular enough understanding of how absolute, relative, and fixed positioning work to where they can mix up the two to form fluid UIs.
They'll make one mistake and not realize it and before you know it behavior starts an inexorable slide in sanity, from which the only recovery is to scrap the entire page and start over. Been there done that.
> You use ALT text by adding the alt attribute with a value of the text equivalent of your image, like so:
> <img src=“https://example.com/image.png” alt=“developer in an office working feverishly to hit a deadline on a software project” />
Is this actually a good idea?
This sounds like a typical "hero" or "teaser" image, to capture the reader's attention or interest. I don't think the alt tag does that in a comparable way, for a screen reader for example. So I'd just leave it blank.
It's really frustrating: all articles on accessibility mention the alt attribute, and that you should use them. But few give guidelines on how to write a good alt attribute that is actually well thought out.
When I write a website that explains things, and uses images, I (nearly) never use only images, but usually images + text. If I put an alt description in the images, I basically duplicate the text, and I guess that will confuse screen reader users more than a blank alt text.
The W3C's Web Content Accessibility Guidelines (the gold standard for web accessibility and the usual legal requirement) only requires that images of text have "text alternatives" - it doesn't require the alt attribute specifically. Your solution to just use text alongside the image should be fine in most cases.
The only practical difference is that with alt text, the blind person is aware that there's a graphic on the page. With alt="" they have no idea the image exists. Does that matter? Maybe in some contexts - you have to use your best judgment on a case-by-case basis.
It also doesn't require alt text for images that are purely decorative and not necessary to understand the content, though this is a bit subjective. Could a blind reader still imagine the idea of a developer in an office working feverishly to hit a deadline, and would that add to their experience of the article enough to be worth including? Again, there are no hard and fast rules here so you just have to use your best judgment.
> It's really frustrating: all articles on accessibility mention the alt attribute, and that you should use them. But few give guidelines on how to write a good alt attribute that is actually well thought out.
You're not alone in feeling this frustration. In fact, this very article includes what I presume to be a screenshot of some code from the React docs. I have to presume that's what it is, because I'm a screen reader user and they haven't provided an alternative, screen reader-accessible version. Go figure.
> An image on a Web site depicts the floor plan of a building. The image is an image map with each room an interactive map area. The alt text is "The building's floor plan. Select a room for more information about the purpose or content of the room." The instruction to "select a room" indicates that the image is interactive.
And how does it help any blind person to know that there is a building plan, but none of the contents of the building plan are described?
Or am I misunderstanding the purpose of the ALT text?
I feel like screen-reader-capable text should always have two options, since so many things in life benefit from a detail option: “give me the tl;dr” with an option for “more” if I want it.
I know it’s hard enough to get consistent support for "alt" at all but an "alt-long" might be nice too so you can say things like alt="Picture of ocean landscape" alt-long="An evening shot of a beach in the Maldives, with a full moon, no clouds and still water.".
Ironically, a great illustration of why pictures are trash for explaining concepts outside of specific scenarios. What exactly is the picture trying to convey? How much time and how many bits did the picture take compared to the text?
Thankfully, my eyesight works. But I’m sick and tired of designers pretending I’m illiterate and replacing text labels with inscruitable icons and graphics. Hey, remember when you could change your preferences by going to “File -> Preferences?” Instead of hunting around the interface looking for an unlabeled gear icon or hamburger icon or whatever some designer thinks conveys the same concept?
My guess is being utterly lazy with localization. They don't want to have some sort of font rendering or anything like that with fixed dimensions or having and then it got cargo-culted from there. Personally I find searchable text far more useful as Ctrl + F "Setting" highlights everything so much quicker especially on large pages.
I also loathe the unnecessary javascript everywhere.
When attempting to open the website I was greeted with:
uMatrix has prevented the following page from loading:
https://blog.logrocket.com/the-easiest-way-to-keep-your-web-apps-accessible-c2b57506cc2a
I never blacklisted the website on uMatrix[0] myself so I checked the list of hosts files I'm using. It's apparently part of Peter Lowe’s Ad and Tracking Server List[1]
[0] Obligatory "How do you know someone uses uMatrix? They'll tell you"-joke. I know, I know... mea culpa
Blog content seems to load with Javascript disabled in Chrome, with the only thing missing being the Clap, bookmark, share icons that follow the side of the article and the account menu drop down.
For some reason, font sizes have shot through the roof in the past few years. Medium is one of the biggest offenders. You get maybe 2-3 paragraphs per page now, when entire articles would fit on a single screen page with normal-sized fonts.
I'm in favor of this. My eyes aren't particularly bad, but I have to use reading glasses in order to read most computer text, and some can get really difficult. Larger fonts are better even for my bad-like-most-other-people-my-age eyes. The tiny text I would have found fine 20 years ago is painful now.
There's an easy fix for folks like yourself: most (all?) modern browsers support setting a minimum font size. Jack that up way into the double digits, and stop justifying ridiculously large font sizes for everyone.
> That would be a much better plan. See what I mean?
No, because there are cases where having large fonts makes sense (e.g. <h1> for article titles, etc) while preserving the ability to display smaller fonts than that (e.g. for article content).
Conversely, you could just ctrl-shift-plus and make the text as readable as you like, since it bothers you and stop justifying the rest of us having to jump through hoops.
Who should have to jump through hoops, the person who cannot read text that is too small, or the person who's sensibilities are offended by text that is too large?
Most operating systems have accessibility options to help with that. Consider helping your mother to use those, they exist for a reason. Punishing everyone just because a few folks need help is not the answer.
But flip the logic. Your inaccessible site, due to tiny unreadable fonts, is punishing everyone whose eyes aren't as good as yours, which is a lot of people.
Or just stick to the basic logic: you can increase tiny fonts, where as on most sites now I can't shrink them. So it is punishing.
Your mother is inconvenienced, we are punished. She only has to adjust one setting, where as I get no option.
And nobody is talking about tiny unreadable fonts, we're talking normal verses gigantic. If she can't read the normal OS font size, shes the problem and not the rest of us.
Yep. That's also how we got oceans of empty, wasted space on each side, necessitating scrolling.
Skimming? Since when does a literate person skim? Just read it, you lazy so-and-so, like you just read a book! A book with gigantic margins, like all books ever!
This is compensating for the fact that font sizes dropped through the floor for years. I recall being told years ago that 16pt font was the desire, but actually most sites were using a LOT of 12 pt (or equivalently close). I even recall reading that, actually, 16pt is not necessarily large enough for easy comprehension of the average reader.
In the past decade designers/PMs have started to figure out that users don't read, so they aren't trying to wedge as much text in. Though I'm no fan of some iOS interface, I credit Apple with getting the concept of legible text into mainstream design thought.
As far as Medium et al goes - I think the idea there is not so much the font size as not wanting to show you more than 2-3 paragraphs, lest you get a "wall of text" opinion and not read any of it.
This is why I disable custom fonts and limit the range in size from 9-13 everywhere. I have a mono and a regular font allowed. I've been doing that for at least a decade.
People use Medium because it's the easiest way to write some plain text and have what you wrote look decent in the browser. That's all it comes down to.
That's not plain text, it's HTML. It's a total fiddle to write by hand (lots of angle brackets), and as you say you then have to find somewhere to host it.
But it also doesn't look as good as Medium. If browser makers were willing to be progressive and act as user agents, like they were originally intended to, then the two would look very similar. Unfortunately web browser text sizes haven't kept up with increasing screen density and so we have point-size inflation instead; the complete lack of margin also makes for a struggle when reading (though I do think Medium has gone too far in the other direction lately). Medium's link styling is less obtrusive; conversely code blocks on motherfuckingwebsite-style sites aren't visible enough. Image sizing on motherfuckingwebsite-like sites is also all wrong (they're sized to pixels rather than to anything meaningful). A lot of sites look worse than motherfuckingwebsite, but Medium is an improvement IMO.
I've always found Medium to only become readable once I use Firefox's reader mode. The interstitial, the aggravating headers and often footers, the utterly useless sidebar icons.
Their styling is unobtrusive, but the result is something that leaves me thinking a designer needs to be shot for working far too hard to justify their pay.
Pretty much. Writing markdown with jekyll is too technical or not WYSIWYG enough for most people who don't want to touch a command line, and running your own ghost/wp/etc blog is too much for the average person to do without using ghost.org or another pay-per-month hosting service.
They offer some kind of website hosting? I can't tell because the entire logrocket.com domain is blocked by "Peter Lowe’s Ad and tracking server list" which I have enabled through uBlock Origin. Not sure if I turned on that list or if it's on by default. Either way, the only other site I've ever get that full domain block warning on is Facebook. I'm guessing they're up to some equally nefarious tracking tactics.
After reading the comments about the article here, I'm not concerned about being overzealous. Seems like it's doing quite a nice job. I haven't needed or wanted to unblock anything it covers so far.
I've been using your list for as long as it's been on by default in uBlock Origin. Facebook is the only other site I've ever hit the block on. LogRocket is such an obvious thing to block, they are selling tracking tools to "replay what users do on your site".
I'm glad this conversation came up. I have your list enable in Firefox Mobile/uBlock Origin too. logrocket.com is in the rule list, but it doesn't stop me from going to the site, or Facebook. I went to "wheniwork.com", one of the "great companies" trusting LogRocket, and it does block their references to logrocket.com. I'm guessing the FF mobile API doesn't allow site-level blocking so sties like Facebook and LogRocket can still run their invasive scripts on their own domains and I won't know about it, unless I find out some other way and remember not to go there. I'm going to have to go NoScript on mobile.
in the 90s, unix developers built web frontends and they were built in this way - simple, with text. they had no skills in graphic design so they kept it simple.
after 2000, graphic designers took over this work and evolved into "frontend" developers. although there were periodic wins like google maps that would have never been produced by the 90s greybeards...most of it has been an endless stream of garbage. but the goatee crowd should not bear all the the blame, some must also fall on the adtech people who insist I need 15 mb of tracking garbage to read a news story.
What about people who don't read very well? I remember just browsing the screenshots on games domain back when I was a kid and could not read English yet.
The easiest way to keep your apps accessible is not making them web apps. Instead of relying on an entirely redundant abstraction layer/OS built on top of your existing one just write native applications.
But if you have to do it in a browsers then at least make it so the actual content (text/images) do not require JS to load and display.
I like the content of the article but did not appreciate the out-of-place call to action to try their service right in the middle of the body ("LogRocket is working on ... Click to check it out.").
In my opinion, those call to actions are helpful when in the similar context with the content itself, or when placed outside of the content. Otherwise they are just intrusive.
I can appreciate hn is mostly humor intolerant but these are all basically right on point. The web experience is now akin to walking the mall; loud, expensive, garbage.
Also please don't use bad fonts. Someone posted the following article the other day and the font drove me so nuts that I had to resort editing the CSS code to make it readable.
I wish I could set reader mode as the default experience. Then, I’d click on something to load the full experience when I know/think it’s needed (and perhaps have my browser remember that choice).
Currently, I can only enable reader mode after my browser has loaded all the shit I don’t want loaded.
Yeah, I know there are extensions for this. I was talking about what I wish for--browsers blocking all the extraneous requests by default and just showing me the page content alone in reader view without downloading all the additional crap.
It's worth considering that one of the many, many wonderful things about the modern internet and modern browsers is that you don't have to sit and wait passively for someone to deliver the experience you want to you. You have everything you need to make Firefox or Chromium do it for you!
Then you can share it with others, and they can have the automagic, fresh-from-the-box, on-by-default experience you would like.
I've been doing this internet thing for nearly 25 years now. I'm not ignorant of all the things I can do on the "modern" internet or browsers. I'm not waiting around passively for someone to deliver experiences I want--I build software, ffs.
I made a simple statement about what I wish browsers did by default. That means no extensions. That means that--unless I'm going to fork a browser to build it myself--building yet another extension to do these things in a sea of extensions that do these things still doesn't change what I wish browsers offered by default. You're now the 3rd person who has appeared to misunderstand the intent of my comment(s).
I fully understood your comment, your point, and your desire. I was attempting to encourage you (and anyone less experienced reading along at home) to push the world that exists in the direction of the world you want, rather than imply any ignorance on your part.
It's far, far too easy for people to treat technology as artifacts handed down from the gods that can only be passively accepted.
> It's far, far too easy for people to treat technology as artifacts handed down from the gods that can only be passively accepted.
Too true. I usually phrase the same sentiment as bemoaning how people treat tech as if it's some magical black box into which they cannot peer & tinker.
Of course, I feel that same way about other things, such as automobile engines. I know it isn't a magical black box, but it may as well be.
Yet, to my mind there's a marked difference between viewing something as a magic black box that cannot be understood and an artifact that isn't understood. The former is an permanent state of affairs. The latter may wind up being permanent, but it can be fixed with effort.
As long as we're making wishes, I'd like my browser--by default--to track down and give a hard slap to all the folks that have ever done any obnoxious stuff with a web page, up to and including Sir Tim. One slap per offending page. I have already prepared my own face for punishment.
If your over-featured site is still readable with lynx, your cheeks shall be spared.
Some visitors want an experience. Others just want information. It is very rare that both types may be satisfied on the same site. If you find that you can build such sites, please report to your nearest zoo, to register for the endangered species breeding program.
Edit: Awww, so close. Sadly, I can see Safari still loads all the crap. So I'd still have to disable/enable JS manually, and have other blocking in place for the extraneous requests that don't belong in a reader view. Maybe one day.
Yeah, NoScript isn't news to me. I'm talking about what I wish a browser would do--out of the box, by default, zero config and third-party add-ons required.
Most people don't give a single shit about your font choice unless it is egregiously unreadable, but the people who do care are especially strident about it.
I tend to prefer leaving it up to their browser default when possible, on the assumption that the few people who really care have customized their browser and don't want me to override it and nobody else will appreciate my refined sensibilities in font selection.
Yes, I am using Chrome on Windows. Thank you for the Firefox suggestion! I didn't realize it was built in now and you can use a serif font. I guess it's back to Firefox!
Blogs are such a waste. I dont need to hear your life story and opinions.
Post the situation, the plan, and details/documentation.
I do not have the time to read a literal 6,000 words.
I for one, do enjoy reading a long article and if I'm busy I will bookmark it/add to reading list for later. Everything doesn't need to be crammed into 280 characters or less. Maybe I'm just old fashioned and should embrace our race to the future presented in the movie Idiocracy?
