The web works best as a document platform. All the UI tricks that web developers work on all end up managing something related to just browsing/reading a document. It's amazing that modern browsers/HTML just don't have this basic user experience down.
Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-form articles, for example, when the basic purpose of the web is designed for reading documents? Why weren't multi-page transitions built in by default?
The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles? Why are there a million JQuery photo gallery plugins?
In fact, why do we need to write CSS to create a basic readable document in the first place? Why doesn't HTML/CSS default to a high-end and legible reader experience out-of-the-box for basic text? (proper fonts & spacings, limiting column widths to 8-15 words max, etc..)
The reader-mode that web browsers are building in, that should be the default standard UX for HTML, and CSS should build upon that. But instead, it's a non-standard option.
> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles
Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays. Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant.
> photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles?
Because there's no one size fits all solution. Look into magazines, newspapers, etc. After a few centuries there is still no standard. Grouped, with captions, position, size, etc.
> why do we need to write CSS to create a basic readable document in the first place
You don't. Browsers can display semantic markup just fine without any CSS. The fact that you even ask this question is why you write CSS, because different people in different times expect different styling, and they don't think the default style is pretty. I agree that the default styles could be improved though after 20 years, but that could lead to breakage of current CSS styles, and why risk that if everybody uses CSS anyway?
And the fact that I wrote this comment is just another reason why you have to write CSS: because not everybody agrees on how the web should look.
It looks like you've brought up the most important point: the design of a page is altered based on advertising revenue.
90% of the JS being loaded is for tracking to increase advertising revenue. Much of the styling for a site that has no advertising can be fairly light.
If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.
> If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.
I would flip that: we need to explore ways to generate revenue which don't rely on practices like trackers, structuring content to inflate page-views, etc. which don't benefit the user.
The most obvious example I'd use is ArsTechnica's approach of disabling ads for subscribers – I notice this any time I use a new browser and pages take twice as long to load because web performance just isn't a priority in the ad world.
>>> If we focused less on revenue generation we'd have a much much smoother web experience
But then rather than poor content, there would be next to no content (for the masses) because business have expenses ;)
Speaking seriously, yeah I see what you mean. Maybe reducing ads and improving speed would result in better UX, which would lead to better user retention, which would leave to more ad clicks. But that's a lot of maybes. Why risk that if people are used to ads? Ads often come when subscription is not an option.
You can explore other revenue sources (e.g. affiliate) but they are usually not widely applicable. And other than that, there's not much to do. I don't really think there exists a business model which could replace ads (when, again, subscription is not an option).
On a related note, I think depending on ad revenues is not such a sustainable practice. Its a feast or famine strategy and eventually a lot of businesses are going to realize that. Targeted marketing improves this, but the greater the noise, the more our brains learn to ignore it. Subscription or sponsorship models are a tougher sell but provide more loyalty and consistency for free content.
> Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant.
Actually yes this is the use-case I was referring to.
HTML has semantics to define sections, headers, etc.. but it doesn't manage them in any way.
If you write HTML that define sections, for example, it's no different than if you write HTML without sections.
What is your opinion of the section-structured HTML documentation itself? http://www.w3.org/TR/html/ It's all neatly sectioned with anchor links and so on.
Section and header tags were standardized last year, it's definitely too early to tell how browsers will handle them, but with the ubiquity of CSS and for the reasons I already mentioned I doubt they will ever get any styling, unless maybe for when no CSS was defined at all.
Ultimately, I don't think of the web as a page-based medium, it's document-based. Electronic documents that want to mimic pages are a relic from the past, imo. What you seem to want should probably be implemented as browser plugins.
> Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays.
What I read was that it's not for "more ad displays", although closely related. It's because news sites keep (and market themselves based on) a "pageviews" metric, so they try to get as many pageviews as possible out of each piece of content.
Have you tried to disable pagination in reading apps like iBooks or Instapaper?
Long articles and books are more comfortable to read if they are paginated: one small tap, one pageful of new stuff. Far more convenient and less prone to losing your place than scrolling.
Not only do I disagree, I would argue its subjective. I much prefer one long article instead of paginated articles and will regularly refuse to continue past the first page on principal.
You may like pagination but I do not, and I would argue its better suited as an option, not dictated by the author.
Using pages to display text is fine. I regularly use space to scroll a page down when reading a long text in the browser because it is more pleasant than constantly scrolling. But fixed pages should not be part of the document markup in most cases. Reading a PDF on my phone is not a pleasure just because I can't just flow the text to fit my device.
I do most of my long-form reading on devices that don't have a space key.
I am not talking about fixed pages or clickbait websites where you have to scroll anyway and then click a "Next" button, but about having a flexible way to enable pagination of content.
That pagination is one of the reasons why for me the best way to read something like the stories in http://longreads.com/ is on Instapaper (or a similar tool).
Yes. I gave pagination in Instapaper a try, and turned it off after about an hour. I tried to turn it off in iBooks, but there doesn't seem to be any such option in the iOS version.
This is only true if you constrain the "web" to mean the Tim Berners-Lee document-centric HTML and its http hyperlinks.
The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a interconnected electricity and have done other things with it.
Do some "native" apps do nothing more than what a 100% static HTML could do? Yes, abuse of a Javascript widget framework does happen. However, the bad examples don't mean the "web" should be held back by the original visions of HTML or Hypercard. The Google maps app is not traditional HTML+CSS.
EDIT: The replies misunderstand my position. I'm not trying to redefine the traditional technical meaning of "web" and make you like it. I'm attempting to explain that "the web" has evolved and what it now means to the world out there. (E.g. see non-document usages like Dropbox, google maps, online Sudoku games, etc.)
This is only true if you constrain the "car" to mean the Henry Ford, transport-centric engine-and-chassis.
The "car" also means the whole transportation stack: pavement, asphalt, road signaling, etc. In that case, the car is a foundation tool for anything that transports people or inanimate objects. To say the "car works best as a transportation device" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a horseless carriage and have done other things with it.
I'm not saying I like for "the web" to be interchangeable with "the internet".
Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on. The "web" has become the "internet" for both documents and applications.
It's descriptive, not prescriptive. (See my other replies to illustrate how usage of http has evolved to coexist with corporate firewalls that lock down ports.)
> Instead, I'm pointing out that the world out there without permission from any savvy HN readers has moved on.
The world has not moved on. Part of the world has dug itself into a technological hole. Most of the people who work in it have never seen what's outside it, so they think the solution to all their problems is to keep digging.
Edit: crap, I sounded so snarky and aggressive. Sorry about that. It's not something personal -- I obviously got the point that you don't think everything about that is a good idea.
The point I'm trying to make is that not ever technological move is necessarily a "good" evolution. Every narrow street in technology was once thought to be a superhighway that everyone flocked to.
I remember everyone being so bloody enthusiastic about this whole Web 2.0 thing back then (and I was one of them). Then all this data crumbled as people paid less and less attention to information structure and semantics and focused on the flashy stuff. Then it turned out a lot of problems were intractable if you clung tightly to JS, CSS and the web browser.
Yet for some reason, people thought those problems happen just because we don't cling tightly enough to JS, CSS and web browsers.
Oh -- and twenty years after operating systems that aren't full of memory leaks, security problems (eh...) and performance clunks became reasonably accessible to people everywhere, people are trying to promote ditching those for web browsers. Which, I would estimate, will need another twenty years or so to stop having memory leaks, dubious security and privacy practices, and embarrassing performance clunks.
To clarify, I'm not saying "moved on" as an objective measure of superior technical progress.
The "moved on" is referencing a descriptive (not prescriptive) state of affairs with how the world now defines "the web". The existence of sliding around map tiles in maps.google.com, syncing folders in Dropbox, etc is evidence that the world does not think of "web" the way Tim Berners-Lee thought of hyperlinked documents in 1993.
Yes, but whatever that is should not be called "web", just like we call "cars"... "cars", not "carriages", though they may look like it.
"The web" is defined by a set of traits (hyperlinks etc.). When whatever we're doing stops having those traits, it's no longer the web. Continuing to call it "the web" is not some form of philosophical awareness, it's just ignorance.
But "computer" used to mean a "person who calculates" and not a "machine that calculates". All of us call modern day devices with CPUs a "computer" even though it lost the essence of "human". The usage of words evolve.
I 100% agree that ""The web" is defined by a set of traits (hyperlinks etc.)".
I'm also adding that "web" also now includes expanded perceptions by everyone else beyond "hyperlinks+http" and that enlarged perception is unavoidable. We could ask the world at large to *not" call it "web" but that's like asking us to quit calling "machine calculator" a "computer". Sometimes we invent a new word, but many times we don't.
Yes, a person uses a "web" browser to read a "document" on New York Times. But they can also use that same browser to play a Sudoku game that's not a document at all. To the layman, both actions are "surfing the web".
By the time electronic computers became widespread, very few non-electronic computers remained -- and few of them were human. The term was easy to repurpose.
But the World Wide Web is very much here and very present.
> To the layman, both actions are "surfing the web".
To the layman, a server and a computer are the same thing, and yet calling Apache a computer is incorrect.
>The term was easy to repurpose.
But the World Wide Web is very much here and very present.
And educated programmers call various text styles, "fonts" even though technically, a font is actually a specific size, and specific weight of a "typeface". The "font" is a subset of "typeface". Even though typefaces still exist, almost everyone uses the word "font."
And programmers will also call SQL (without CTE) a "programming language" even though it's not Turing Complete.
Even binary black-&-white-thinking programmers will exercise a lot of leeway with how words are used.
I want to emphasize that this all started with my response to the "web is best as a document platform."
I think most of us can substitute "web" to say "http+html is best as a document platform." That's what TBL meant.
Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as reality, what does "web" in "web app" really mean? The "http+html" has become a universal transport mechanism (with some apps even tunneling through http to do interesting things.). As the years progress, there are more examples of http becoming a "dumb and dumber" generic transport pipe for things that are not documents.
Let's say a startup company wants to create a website to crowdsource music promotions. They want the service to offer programmable access so people can write open source clients. The presentation slide / whitepaper will not use the phrase "internet api". Instead it will use "web api". If every corporate firewall and user' homes computers with Microsoft Firewall had wide open UDP ports, it's possible for the phrase "internet api" to have more currency than "web api". But that's not how history has played out.
> Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as reality, what does "web" in "web app" really mean? The "http+html" has become a universal transport mechanism (with some apps even tunneling through http to do interesting things.).
HTTP + HTML does not include "the whole Internet stack, TCP/IP, DNS routing etc.", as you mentioned above.
You're right. 1000x I agree that TBL's http specification and the html specification is not TCPIP and DNS.
However, that wasn't the level of conversation I was trying to have.
There is another viewpoint of http+html that is not the specification. That viewpoint is the usage of http/html/TheWeb.
For example, the White House is building made of stone. It is not a human. So how can newspapers say "the White House has signed the Internet Freedom Act into law." Well, we're not getting anywhere going round and round in circles insisting that stone buildings have no agency to pick up a pen and sign a document and that only a human like President Obama can do it. There are multiple meanings of "White House" and we seem to get along fine with it.
There are also multiple meanings of "web." It's possible for the industry to invent a totally separate word besides "web" for the abuse/reuse of http+html as a transport for apps but that didn't happen. If a startup in Silicon Valley has a goal to release an app that makes use of TCPIP+DNS with the best chance for wide adoption, they can entertain the idea of using a custom UDP+port scheme... or they can just piggyback on http. They didn't use http as Tim Berner-Lee's specified in 1989. It's the out-of-spec usage that's adding new color to what modern "web" means.
I'm not saying I approve of it or it's technically superior. They didn't ask TBL's permission for it to evolve that way. Is it anyone's fault?! Too late to assign blame now. It is what it is. The phenomena I described above exists no matter what label we give it. It would be awesome if another word besides "web" described it but it doesn't exist (yet).
If the "White House" can act as a synonym for "human", it's not impossible for "web" to act as synonym for "whole internet stack." (Again, the synonym mapping is using the other evolving definition of "web" instead of the official RFC specifications.)
>The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In that case, the web is a foundational tool for anything that connects people or Internet Of Things. To say the "web works best as a document platform" is like saying "the electricity grid works best as a lightbulb platform." We've gotten past the historical motivations of a interconnected electricity and have done other things with it.
No, absolutely not. The "web" refers only to what you mentioned above. It's only a recent bastardization that we started referring to the "Internet" as the "web", because of the dominant nature of HTTP. You're right though that the Internet is important, but the GP's point stands that HTTP was really only intended as a document protocol (Hypertext, yeah?) and it has seems a somewhat strange perversion that we've bent it to doing so much more.
Someone not in the know may call the transmission in a car "an engine", or call the differential a transmission. Just because someone outside of the industry does silly things like that doesn't mean all of a sudden obfuscate the usefulness of terminology at all, as it really helps no one.
Those were the historical and technical divisions.
Because http & https is ubiquitous and they have a defacto pass through most firewalls, the modern "web" is the "internet" as far as application interfaces are concerned.
The idea of a pure separation of concepts such that http is "documents" and some other protocol on some other port is "apps" is not going to happen. All those IT departments' security teams and Cisco admins at Fortune 1000 companies are not going to adjust their firewall rules to open new ports and protocols. The "http port 80" has become the "internet" on top of the old definition of "internet". It's not ideal but that's where we are today.
I think we need another rule of thumb here: All standards will be modified by public cluelessness, and exist as uglier de facto distortions of themselves.
I don't see how willfully blending these two things is helpful for anyone.
In this context, it can be safe to assume that everyone knows this technical distinction (even for those of us who are not web programmers). In other contexts with less computer-technical people, I don't think being annoying and correcting every "technically incorrect" mention of "The Internet" when they mean The Web is helpful. But I think it is helpful to remind them of the distinction if you are actually talking about the subject (as opposed to just saying things like "look at your internet, I just sent you a facebook message"). Computers are magical enough as it is; it doesn't help anyone to make it even more so when they are even slightly interested in discussing some part of computing or IT.
Explaining that The Internet is the infrastructure and the Web is just one the things that uses this infrastructure seems simple enough to grasp, and isn't an oversimplification at all. People understand that the electricity grid has to exist in order for them to make toast.
So, is a HTTP (Hypertext Transfer...) REST API used by a native mobile app "web" or not?
How about a native app based on a "web view" that uses HTML, CSS, JS, etc. (the whole W3C stack) and doesn't even talk to HTTP/S but uses some other port and transport mechanism?
I thought I was clear that I'm not using the traditional definition of "web" but to explain what "the web" has become.
It's about the evolution of how society sees the web and not about what its original purpose is.
Dropbox uses html and http. Drew Houston and his team are not going to submit an RFC so that the internet has a new protocol and port "dropbox://myaddressoffiles:8675". No, Dropbox the application will just use "http://". It's because they did not pursue conceptual purity of having "dropbox://" that allowed everyone inside and outside of corporate networks to use the service and share files.
That is "the web" we have today and in that scenario, the non-technical use of "web" includes the underlying internet stack to make web apps possible.
What's the alternative? Tell millions of Dropbox users that such a service is outlawed because "the web is best as a document platform?"
My experience is it's the other way around. I am the Technology Director at a school, and when a teacher tells me "the Internet is not working," he is saying that when he clicks on the Internet Explorer or Chrome icon, he's not getting what he expects. Rather than the web becoming the Internet, to them, them Internet is only what they see through the browser. The fact that Dropbox or Facetime also uses the Internet does not occur to many people.
The "web" as in Tim Berners-Lee(TBL) "world wide web" is http+html which is "documents".
Saying TBL-web is "best as a document platform" makes perfect sense. It was defined that way therefore, use it that way. It's tautology.
Back in 1993, if we want to say "X is best though of as a network app platform" we'd have to use the word "internet" instead of "web" for "X" to be conceptually pure and technically correct (the best kind of correct.).
But now we have things like Dropbox (and thousands of other "web apps"). Dropbox runs on "http".
Dropbox "syncs". Syncing is an app. Dropbox is an app. Dropbox runs on http. Http is "the web". Apps run on the web. The web is platform for apps. That's the reality of where we are today.
Dropbox without using http_port_80 would only work in a laboratory. One big reason Dropbox is valued at $1+ billion dollars is that it uses http so everyone can use it easily. Web browsers didn't require radical changes. Corporate firewall rules didn't have to change. That's how they got quick adoption and millions of users.
> The "web" also means the whole internet stack, TCPIP, DNS routing, etc.
I'm pretty sure there are different protocols for email, torrent, etc. And I don't see how that is a bad thing, or why The Web has to be a frontend to everything that comes from The Internet (desktop email application for instance).
Strong disagree on both of these points. I view most webpages (including that one) at around 66% zoom these days, because the text is so goddamn big. And anyone advocating for less contrast needs a shovel to the head.
Likely this hasn't been done because it would require many very difficult, "subjective" decisions to be made i.e. which font, line-spacing, photo-viewer UI, etc.? Better to make no decision at all than to spawn a few dozen endless committee debates.
By contrast, corporations can more easily make these sort of decisions – by fiat – which is why native app frameworks are more "opinionated" / make more design decisions for you out of the box.
This topic is as much the story of two historical forms: the operating system GUI and the World Wide Web hypertext project as it is about two organizational forms: hierarchical corporations and decentralized design-by-committee non-profits / multiple competing corporations.
> After 25 years, why do web designers need to create their own page transition mechanics for long-form articles
As far as I am concerned those things only exist to inflate ad views, they have negative usability impact.
I don't really see why a long document should be broken up in pages to be readable.
> The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles?
There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with.
> In fact, why do we need to write CSS to create a basic readable document in the first place? Why doesn't HTML/CSS default to a high-end and legible reader experience out-of-the-box for basic text?
I find plain un-styled HTML to be much more readable than the tiny light gray webfont on white background that designers usually settle for these days.
> There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with.
Except when people nest the images as deep as posible and overlay other elements in front of the images so you can't simply right click the image, you have to inspect source and hunt for that image URL (or check resources tab in developer mode, or whatever).
That usually happens because someone has decided they need some special javascript "gallery" for the user.
Twitter's default user timeline is the worst example of this that I know.
Don't forget that you can specify related pages as <link rel="next/prev" /> and let the browser handle pagination.
I recall when I used Opera, you could scroll down, hit space, and it would go to the next page as long as the website provided that information (forum softwares often do.)
I also mentioned the column width because this site has the obvious problem of long horizontal text, which is a no-no. People naturally read in chunks of 10-15 words scanning vertically. Long, horizontal text is easy to lose track of location.
How much have browsers invested in their pagination solution, though? If I specify that tag on my pages, does that mean users who visit my site will have an awesome experience when it comes to pagination?
Why is it virtually impossible to read long articles on a web browser? After 25 years, why do web designers need to create their own page transition mechanics for long-form articles, for example, when the basic purpose of the web is designed for reading documents? Why weren't multi-page transitions built in by default?
The same with photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles? Why are there a million JQuery photo gallery plugins?
In fact, why do we need to write CSS to create a basic readable document in the first place? Why doesn't HTML/CSS default to a high-end and legible reader experience out-of-the-box for basic text? (proper fonts & spacings, limiting column widths to 8-15 words max, etc..)
The reader-mode that web browsers are building in, that should be the default standard UX for HTML, and CSS should build upon that. But instead, it's a non-standard option.