The easiest way to keep your web apps accessible: Just use text
blog.logrocket.com
blog.logrocket.com
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.
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.
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.
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.
[0] https://developer.mozilla.org/en-US/docs/Web/API/History#Met...
Broad support for history management is well-established at this point: https://caniuse.com/#feat=history
(Ironically, these days I'm relieved when I see a presentation is posted as a PDF: https://people.apache.org/~xli/presentations/history_Intel_C.... I'd much rather load a PDF than deal with all the shitty and insane ways people have figured out how to show presentations in HTML. Cough SlideShare: https://www.slideshare.net/garyachy/dpdk-44585840)
This is just not my experience, at all. I'm extremely sensitive to this issue, and its just not something I see all that regularly any more.
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.
Good luck getting a group of people to agree on what "non-broken" back button behavior is.
Unless you mash the back button really quickly ...<sigh>
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.
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.
The web was not designed for such use, yet we continue to stretch and abuse whats there and wonder why most sites suck and get it wrong.
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.
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.
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.
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.
I wouldn't be surprised if most if not all tutorials ignore it as well.
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."
Just don't.
PubMed.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3968624/
(There's still a legacy fallback.)
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 guess it might just bother me so much because it shows a fundamental misunderstanding of how the web works.
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.
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.
Is this everyone else's experience? How has web design been taught lately?
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.)
To track clicks.
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.
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 wonder why these limitations. Especially since you can get past this with an:
button.addEventHandler('click', () => {
fetch('/path/to/resource', { method: 'DELETE' })
});
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.
<button formmethod="POST">
<button formmethod="DELETE">
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.
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.
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?
http://blog.moertel.com/posts/2005-10-25-google-web-accelera...
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.
Yes, I agree it sucks. But there are also no great alternatives without JS.
I’d rather style the thing to look the way it should rather than apply unusual functionality to something.
Maybe we should investigate this ancient tech of the old ones.
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 think these meandering rants are a tad silly.
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.
Allow me to one-up with this: https://github.com/medialize/sass.js/
> API for emscripted libsass to run in the browser
And probably accessibility tools for the blind.
pastebin.com/6Q8WT9WJ
For chrome there is a switche at settings > accessibility > show simpified view
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 :)
79.2KB to load home page
sub-second load
7 total requests
In contrast... where I work, to load our enterprise webapp's home page (running on Angular, WebAPI, many external CSS/JS "plugins"):
5.7MB to load home page
28.95s to load everything
173 total requests
Granted we're serving a way different goal, but still... i admire how lightweight your site is.
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.
I think this is the number one reason why I prefer mobile dev over front-end web dev.
Buttons can be styled.
Why does there even have to be a button? I want an API not a button...
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.
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....
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.
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();
You can leave <input type=file> around if you want to submit data via <form> and not via XHR.
You’ve just replaced them with stupid DOM hacks.
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.
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.
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.
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.
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.
Flex and grid are more intuitive so they're easier for juniors to train up on.
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.
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.
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).
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.
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.
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. :)
> <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.
Am I totally off base here?
> 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?
That assumption is that the rooms are selectable, so "tabbing" with a screen reader will select each and speak their Alt text.
Just kidding of course. I always put blank alt attributes on images that are used purely for decoration, and nobody has complained.
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.
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.".
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.
The irony is that people go to medium because it's kind of .. expected somehow? And looks more authoritative?
I'm honestly curious how Medium is an improvement over that. Are you referring to the technical challenges of hosting content, perhaps?
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.
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.
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.
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.
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).
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!
/s
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.
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?
I also loathe the unnecessary javascript everywhere.
uMatrix has prevented the following page from loading:
https://blog.logrocket.com/the-easiest-way-to-keep-your-web-apps-accessible-c2b57506cc2a
[0] Obligatory "How do you know someone uses uMatrix? They'll tell you"-joke. I know, I know... mea culpa
[1] https://pgl.yoyo.org/adservers/, https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hos...
I did a quick Google search on them, It's kinda ironic
>LogRocket helps you understand problems affecting your users, so that you can get back to building great software.
* https://www.reddit.com/r/YouShouldKnow/comments/97an7p/ysk_r...
They also describe their service:
> LogRocket lets you replay what users do on your site
ie, they track everything you do when you visit a site using their service.
I've updated the entry to just block this instead:
logs.logrocket.com
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.
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.
Matt Gemmell, from aa few years back:
https://mattgemmell.com/staying-creative/
Matthew Graybosch
https://www.matthewgraybosch.com/starbreaker/
Mark Pilgrim's Dive Into HTML5 is a classic.
http://diveinto.html5doctor.com
Outline is a lifesaver: https://outline.com
(Especially for browsers/platforms w/o Reader Mode.)
I've also got an entry in the motherlovin' website contest.
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.
https://en.m.wikipedia.org/wiki/National_Federation_of_the_B....
https://en.m.wikipedia.org/wiki/National_Federation_of_the_B....
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.
1) Just use text
2) Make all your graphics into an otf font
3) Use CSS to style everything including backgrounds
The ONLY place you may need graphics is user submitted content like profile photos.
https://blog.bugsnag.com/bug-day-race-condition-therac-25/
I really wish "reading mode" was a prominent feature in desktop browsers.
What do you mean here by "prominent"?
Currently, I can only enable reader mode after my browser has loaded all the shit I don’t want loaded.
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.
If they can't force you to watch their ads they just want you to go away.
I mean, just look at the backlash against AMP.
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 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.
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.
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.
By "desktop browsers", do you just mean Chrome?
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!
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.
An official keyboard shortcut for going to reader mode.
The option of having the browser send all articles to reader mode when detected as possible.
font-family: sans-serif;
https://news.ycombinator.com/item?id=17721496
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?