You're right, it's not the same. Scratch is too Computer Science-y for something that can be as simple as a website. Text, images and video, plus hyperlinks that link one page to another. That's enough for the majority of people to share information.
I really hope something comes along that reinvigorates the public's interest in creating content that resides on their own website, rather than a walled-garden social media account.
I love that you kept the style too. This brings back good memories. I’ve learned HTML using Frontpage and gifs were a must in my geocities hosted websites.
One of the most prolific and well-known music reviewers - Pierro Scaruffi - has a website built in 1995 with a design not updated much, or at all, since: https://www.scaruffi.com
The biggest drawback of sites from this era is they don't reflow on mobile screens. On a desktop they still work as well as they ever did. I'm still searching for a good WYSIWYG HTML composer that can generate clean, responsive pages. Seems like this is a problem where there isn't sufficient incentive for the big tech companies to tackle, and the only s/w that seems to come close is BlueGriffon.
That's a client side problem, not a server side problem. The rendering and presentation of a webpage are entirely up to the client, absolutely nothing dictates that a page should look a certain way on a certain client.
There are a ton of attributes in the HTML that dictates how the website should render - it has a bgcolor and a margin on the body tag, a width and height on the main table, center tags all over the place, etc. Suggesting that a browser should ignore the HTML spec and do something else would completely destroy the web.
User agents already can ignore css and have user defined stylesheets and even JavaScript. None if this is new and it's a failure of our profession that that is abnormal and produces spectacularly poor results for users.
Users should be able to override the default behaviour of their browser if they want to, but the default behaviour should still be defined by the HTML spec rather than the browser vendor.
It's really frustrating when two browsers implement important parts the spec differently and push website developers to work around the behaviour one browser or the other with browser-specific code. It doesn't lead to sites being rendered differently as developers embrace the variety of user agents. It leads to people adding "This site is best viewed in Netscape Navigator" gif or "This application requires Chrome" on log in pages. Those are bad things.
Maybe the solution is to let go of this notion that every device needs to render exactly the way the designers want and embrace that difference.
I've been on the internet since the mid 90s. I'm well aware of what was, andit was that way because people then as now wanted things to look and act exactly like they wanted and not embrace that not everyone wants or needs your carefully crafted graphical design.
I don't have any notion that sites should be exactly the same in every browser, but they should be approximately the same. Having two browsers render the same HTML in completely different ways would be very odd.
You should, and the browser should let you. But if the text is set to 14px in the HTML or CSS and your browser is set to display it at the defined size, it should display at 14px. Browser vendors shouldn't decide to ignore the spec of using the defined size and do their own thing instead. That's what was being suggested.
That's a user derived choice. I'm not saying user's shouldn't be able to change the way a site is laid out if they want to. I'm saying that by default it should use the HTML spec.
I shouldn't bother mate. It is fast and the content is easily accessible. I've just spent a happy half hour browsing your blog. It looks like you'll be "needing" a 3D printer soon to really waste time on building IoT stuff.
I have five different models of ESP8266 and ESP32s scattered across my desk along with Dupont wires, assorted sensors and a soldering iron, breadboards etc. Its a great way of taking your mind off the daily grind - my job title is MD.
So I wanted to link my 23 year old website, but precisely because it's still updated, it looks like this: https://www.stavros.io/
It's gone through many renames and redesigns, but, in true Japanese style, it's still the same website. I do have an old snapshot, though: https://anonymoussoftware.stavros.io/
You too! It's interesting, though, my friend who now lives in the US always remarks on how, in the US, you can just drive mindlessly on autopilot, whereas here you need to be paying 100% attention at all times due to people always swerving in and out of stuff.
Similarly, I feel a continuity in how old my website is, but in Ship of Theseus fashion lots of little parts changed over the years (and pieces were lost to storms, etc). I was really excited at one point to find an old time capsule of a snapshot from a particular redesign I recall being fond of around 1999: http://worldmaker.net/wmo99/
Amusing to myself and contributing to overall Ship of Theseus analogy, the current design is a responsive, flexbox-based recreation of sorts of the original goals for that 1999 site. I'd like to think the 1999 version of myself would very much appreciate it (especially after all the work in making corner GIFs versus the magic of CSS border-radius, and fighting TABLEs for layous).
My oldest content is from 96 or 97, but the page only exists offline. Hand written, of course, in pico - back then I didn't really know the web existed we just had www/ directories on our Uni's Unix accounts. Around '97 I updated to have frames, then '98 I think was SSI.
From that document:> and some countries separate thousands groups with a thin space
Thin space (U+2009) is also how you are supposed to do it when using the SI unit system, according to the SI spec. For the decimal separator, the SI standard is to use which of '.' or ',' is customary.
He is a member of the Cherokee Nation with interests ranging from model railroading to fireflies. And he puts it all out there on his personal webpage, updated regularly since 1996. There was a time when it was normal to stumble upon pages like this one.
Have you actually tried the site on a mobile device? It's impossible to read the text and navigation is hell. Wouldn't classify that as "mobile friendly".
Most mobile browsers support it out of the box. If the site designer set "user-scalable=no" in the meta viewport property, than that will prevent zooming. It's an accessibility issue and should be avoided.
I am sorry, you’re totally right, is it pretty unreasonably nit picky to differentiate between 10 inch screens and 3 inch screens when it comes to web UX. Smart phones do count as all mobile devices and the only thing that matters when determining if a site is mobile friendly. And of course it’s usually a good idea to broaden the argument categorically to something larger than your personal experience to make the stronger point that most people would agree with you and the other person is obviously up in the night.
You say that as if it’s weird to call an iPad a mobile device. Would you say that a tablet is not a mobile device? What do you define as mobile device, and what devices would you use to determine if a web site is “mobile friendly”?
The common definition of mobile device is phone or tablet. The common definition of laptop is computer. These despite the fact that phones and tablets are computers and despite the fact that laptops and even desktops can be moved. It’s pretty easy to find lots of examples of the common definitions. Here’s a good one: https://en.wikipedia.org/wiki/Mobile_device
The question of whether definitions matter when one sub-category or subset is a minority or majority... I’m not sure how to answer that. Why would a definition stop mattering just because something different is a small subset? I must assume that a categorical term includes everything in the category. If you don’t mean everything in the category, then don’t use the term that refers to the category. If you mean phone, then say phone. ?? Right? I’m confused why you would argue anything else.
I find HN to be one of the best mobile websites. It's fast and text isn't massively oversized. You can actually fit information on screen. Many mobile websites I've seen are horrible to use, because they have very poor information density and the sites seem to be designed for 4" or smaller screens.
What do you mean? It has reasonable column width so you can zoom in and out as necessary, often with a double tap. That is, it leaves it up to the client to adjust as necessary -- in contrast with the typical mobile site, which:
1) Forces a particular size/resolution, locking out zoom capabilities
2) Has a floating header with a constant size relative to your device screen, blotting out the same real estate no matter how much you zoom. And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.
Yes, this site is better than 99% of mobile sites out there.
Edit: Some further comments: It's generally better to have a site that obeys the standards and thus plays nice with any client, than one that locks you into the hip designer's meth-addled decision. This site in particular works well with my extensions like VimFX for clicking links from the keyboard.
That's the thing - it shouldn't be necessary. I don't do that on desktop browsers; why should mobile devices be any different? If the site is not legible, I set the desired zoom once and I'm done. There's no need to go back and forth.
Now, I can't do that if the elements stay mismatched on mobile. I have to zoom in and then back when I want to interact with small elements - each time. It gets old when I have to click tiny links or upvote arrows more than a few times. It's jarring and not a good user experience.
> And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.
The floating header issue notwithstanding (I don't like them either), this is exactly why the web designers should tailor their elements to different viewports.
> It's generally better to have a site that obeys the standards
Yes, and that also includes accessibility guidelines. Compatibility with keyboard navigation is one of them, but so is the size and spacing of the controls, links, and buttons.
True. Zooming in shouldn’t be necessary. And mobile sites shouldn’t use floating headers or footers. And they shouldn’t hijack interface modes. And they should pick sizes that don’t feel like a straitjacket or make it seem like you’re peering at it through blinds. And they should be accessible and standards compliant.
But I wasn’t comparing to the three or four mobile-optimized sites that satisfy all that. I was referring to the more typical millions that don’t.
And yes, given how bad they are, I’d much rather have suboptimal design that I can recover from with a pinch or a double tap than one I can’t.
What would you cite as an example of a mobile site that is more usable than this one?
> What would you cite as an example of a mobile site that is more usable than this one?
This one being the Italian one from the submission or the Hacker News itself? I'm assuming the Italian one. Off the top of my head, sites with good mobile version and similar structure (lots of text and links) are Wikipedia and The Guardian. One tiny nitpick are tables with multiple columns in Wikipedia articles. This is a common struggle and I haven't found an elegant way of showing data-dense tables on mobile screens.
But other than that, all the elements on both of these sites are big enough, I don't have to zoom in, I don't have to scroll sideways, there are no floating elements, and they have distinctive style. They even work well with a dark mode add-on on Mobile Firefox.
Yes, Wikipedia is one of the better ones! But even so, I still find myself switching to the desktop version whenever I need to link a specific section, or get more of the text in view, or view the article in a different language, or not lose my section when come to a page via the back button.
I checked out Guardian.co.uk (assuming that's what you meant), and yes, it is a pretty well designed site that works great on and doesn't seem to even distinguish mobile vs desktop users. But still, this is about the only mobile site I couldn't find anything wrong with. This isn't the typical 99% site.
Back when Netscape 0.9 was new I had daily arguments with some of the "web designers" who insisted on using HTML targeting browser bugs and other invalid HTML tricks to optimize the aesthetics of their sites.
All you needed to do then, and today, is make sure your HTML is valid and that you don't break things on purpose ("this site optimized for MSIE1.0" type of stuff) and your site will forever be mobile and any-other-html-rendering device friendly.
100 points on pagespeed is not that hard with static sites.
- drop 99% of the JS (PWA, lazy-loading, infinite scroll, jquery, you don't need any of them for a webpage), convert the remaining for 1% to vanilla js and use it as progressive enhancement.
- use EM or % as layout width/height
- inline css, js, and svg
EDIT
- no webfonts!
The only thing that'll remain as an issue are tables wider, than viewport, on mobile.
Don't know about PWA. Service workers are pretty lightweight and help with caching.
But yeah, lazy-loading, infinite scroll, etc., are all designed to cover up design flaws that impact performance. I think lazy-loading can be potentially done right, but almost none of us do anything right.
> use EM or % as layout width/height
Why? EM/REM is good for handling font sizes, but for anything else it may not make sense and a custom font setting in the browser can break layouts if the size of boxes are based on font sizes. PX is perfectly adequate for layout, and is actually a relative unit(PX !== hardware pixel). Same for borders, padding, margin, etc. Even REM is better than EM for most cases. People who adjust the font size in their browser don't necessarily want their layout to change and potentially degrade as a result.
> inline css, js, and svg
Can be a good idea, especially if you can somehow identify the CSS used on page load and discard anything nonessential. Though maybe HTTP/2 makes inlining obsolete. IDK
> no webfonts!
Thank you! Web fonts are perfectly sufficient in 99% of cases.
> Why? EM/REM is good for handling font sizes, but for anything else it may not make sense and a custom font setting in the browser can break layouts if the size of boxes are based on font sizes. PX is perfectly adequate for layout, and is actually a relative unit(PX !== hardware pixel). Same for borders, padding, margin, etc. Even REM is better than EM for most cases. People who adjust the font size in their browser don't necessarily want their layout to change and potentially degrade as a result.
I had a lot of bad experience with px, but it is true that for borders it's the only reasonable choice.
REM is not that well supported, especially in awkward browsers (Dillo, for example).
Imo EM is nicer for padding/margin; it keeps the text/layout ratio even if the font is resized, unlike px.
But point taken, it cannot be used as the only unit.
Here is a life-saver maintained by a 77 year young lawyer for a lot of public good: http://www.drtsolutions.com/. Case laws against SARFAESI, an Indian law that expedites bank recovery for non-performing assets. He updates it manually in FrontPage even today!
Page colors are ugly as shit, but so readable - modern web devs/people who make them do "modern" stuff, you suck compared to these sites in this thread.
I remember how she was ridiculed on Dragon's Den,yet she's the one employing a bunch of people and having a successful business. I remember reading that she's even hired someone to do some maintenance in the town,because the local council couldn't afford it anymore.
It's impressive the amount of content inside! There are countless pages about literature, religion and physics. It's a good reminder of the original goal of WWW: share information.
> It's a good reminder of the original goal of WWW: share information.
That is what I miss the most about the old web. We wanted to build something better by sharing knowledge. And for a while we did. Then mainstream came and corporates took over.
Anyone else still sad over the demise of FrontPage Express? It did everything I needed at the time, it was free, and really easy to use. The HTML wasn't as bad as FrontPage either.
I got my start with web dev using Netscape Composer, which was a similar enough tool. Seamonkey, the successor of Netscape and Mozilla Suite, still includes it to this day and it works well!
While <marquee> support is near universal, I was sad to find out that <blink> has not fared so well.
I'm sure a lot of you already know this easter egg, but if you search "blink tag" in Google, Google makes all the blink tags actually work (using JS of course but still)
My personal/hobby business web site (https://www.rlvision.com) is based on code 22 years ago. It's built with tables, because that's how you did things back then. The age shows. But I haven't found reason to rebuild it yet. Simply put, it works. It may not be mobile friendly, but the goal is to make available my Windows software, so my aim is desktop users.
This website looks extremely familiar. I think I visited it about 15 years ago and I am not completely sure but didn't you have a nice drawing and photo editing software there? I can't remember the name of it but it was the best ever, until it was disappointingly discontinued because of lack of buying customers :(
Yes, ArtGem (https://rlvision.com/artgem_about.php). We were a couple of guys that tried at making shareware, but sadly failed. I continued running the site to host my own utilities, some of which eventually turned into shareware. I don't earn much money from it, but I enjoy making software and it makes me happy when other people find them useful as well!
So nice to hear from the developer of some software I very much liked and used as a kid. I especially liked the smudge feature. You definitely made me happy and I thank you for that.
It's funny to me that one reason why people said to stop using tables was because of file size. Now we have everyone download almost a megabyte (or more) of javascript to render a few kb of html.
I don't recall page size being a reason. I recall TABLE layouts being a lot smaller than most of their alternatives at the time (FRAMESETs in particular come to mind, because we knew HTTP connection overhead was a thing even back then and needing separate files for each individual website "part" felt like a huge bandwidth waste back then).
The big problem was always Accessibility-related semantics. Websites laid out in TABLEs were often quite confusing to screen readers, as TABLE has a lot of supposedly important semantics in how it should be read/engaged with and using a TABLE for layout follows none of them. (What does a table header mean in a layout? Most layouts wouldn't have good headers. How do you describe what a table column is supposed to be for without a column header?) It's a shame that narrative was never clear enough that Accessibility was always the big reason TABLEs were considered a Bad Idea for layout.
(Speaking of downloading a megabyte of data, I recall how long I felt that a 1.44 MB floppy was the best restriction for the size of an entire website. If it was bigger than a floppy you were probably doing something wrong. I stopped counting floppies a long time ago; that person might be ashamed at how many floppies a typical website downloads these days.)
486 comments
[ 2.5 ms ] story [ 318 ms ] threadI really hope something comes along that reinvigorates the public's interest in creating content that resides on their own website, rather than a walled-garden social media account.
https://web.archive.org/web/20200214134509/http://www.fmbosc...
Love it!
It's really frustrating when two browsers implement important parts the spec differently and push website developers to work around the behaviour one browser or the other with browser-specific code. It doesn't lead to sites being rendered differently as developers embrace the variety of user agents. It leads to people adding "This site is best viewed in Netscape Navigator" gif or "This application requires Chrome" on log in pages. Those are bad things.
I've been on the internet since the mid 90s. I'm well aware of what was, andit was that way because people then as now wanted things to look and act exactly like they wanted and not embrace that not everyone wants or needs your carefully crafted graphical design.
Or completely normal? Why shouldn't I bump up my minimum don't size to help read text and reduce eyestrain? Ditto for fixing low contrast text.
You need a dev team implementing Agile for react-native-ux with CI/CD capabilities and devops.
I have five different models of ESP8266 and ESP32s scattered across my desk along with Dupont wires, assorted sensors and a soldering iron, breadboards etc. Its a great way of taking your mind off the daily grind - my job title is MD.
It's gone through many renames and redesigns, but, in true Japanese style, it's still the same website. I do have an old snapshot, though: https://anonymoussoftware.stavros.io/
thats quite a conversation starter...
Hint: "Liar" is the lie.
I am a below average driver, alas. I am Greek, though, and some would say that's more exciting!
From what I've heard, you might as well smash your side mirrors off at the dealer when you buy a car, aha...so, yeah, checks out.
I hate driving here.
Amusing to myself and contributing to overall Ship of Theseus analogy, the current design is a responsive, flexbox-based recreation of sorts of the original goals for that 1999 site. I'd like to think the 1999 version of myself would very much appreciate it (especially after all the work in making corner GIFs versus the magic of CSS border-radius, and fighting TABLEs for layous).
https://godaddy.com/domain-value-appraisal/appraisal/?checkA...
https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/ind...
Thin space (U+2009) is also how you are supposed to do it when using the SI unit system, according to the SI spec. For the decimal separator, the SI standard is to use which of '.' or ',' is customary.
Loads super fast.
> My charge for typical business or civil work is $450.00 per hour.
To one that said:
> I am a relative newcomer to the world of turtles.
...in two clicks. I love this site.
Also learned a recipe for a quick and easy blackberry cobbler[0].
[0]: http://www.burger.com/bcobbler.htm
Probably not ;)
> Initial release 1993; 27 years ago
https://en.wikipedia.org/wiki/HTML
My favorite in High Scool was http://ripmat.it
That site is the only reason I managed to learn Math school
The common definition of mobile device is phone or tablet. The common definition of laptop is computer. These despite the fact that phones and tablets are computers and despite the fact that laptops and even desktops can be moved. It’s pretty easy to find lots of examples of the common definitions. Here’s a good one: https://en.wikipedia.org/wiki/Mobile_device
The question of whether definitions matter when one sub-category or subset is a minority or majority... I’m not sure how to answer that. Why would a definition stop mattering just because something different is a small subset? I must assume that a categorical term includes everything in the category. If you don’t mean everything in the category, then don’t use the term that refers to the category. If you mean phone, then say phone. ?? Right? I’m confused why you would argue anything else.
My further comments: https://news.ycombinator.com/item?id=22328505
1) Forces a particular size/resolution, locking out zoom capabilities
2) Has a floating header with a constant size relative to your device screen, blotting out the same real estate no matter how much you zoom. And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.
Yes, this site is better than 99% of mobile sites out there.
Edit: Some further comments: It's generally better to have a site that obeys the standards and thus plays nice with any client, than one that locks you into the hip designer's meth-addled decision. This site in particular works well with my extensions like VimFX for clicking links from the keyboard.
That's the thing - it shouldn't be necessary. I don't do that on desktop browsers; why should mobile devices be any different? If the site is not legible, I set the desired zoom once and I'm done. There's no need to go back and forth.
Now, I can't do that if the elements stay mismatched on mobile. I have to zoom in and then back when I want to interact with small elements - each time. It gets old when I have to click tiny links or upvote arrows more than a few times. It's jarring and not a good user experience.
> And, of course, using the same header pixel height for portrait vs landscape, making the latter practically unusable.
The floating header issue notwithstanding (I don't like them either), this is exactly why the web designers should tailor their elements to different viewports.
> It's generally better to have a site that obeys the standards
Yes, and that also includes accessibility guidelines. Compatibility with keyboard navigation is one of them, but so is the size and spacing of the controls, links, and buttons.
But I wasn’t comparing to the three or four mobile-optimized sites that satisfy all that. I was referring to the more typical millions that don’t.
And yes, given how bad they are, I’d much rather have suboptimal design that I can recover from with a pinch or a double tap than one I can’t.
What would you cite as an example of a mobile site that is more usable than this one?
This one being the Italian one from the submission or the Hacker News itself? I'm assuming the Italian one. Off the top of my head, sites with good mobile version and similar structure (lots of text and links) are Wikipedia and The Guardian. One tiny nitpick are tables with multiple columns in Wikipedia articles. This is a common struggle and I haven't found an elegant way of showing data-dense tables on mobile screens.
But other than that, all the elements on both of these sites are big enough, I don't have to zoom in, I don't have to scroll sideways, there are no floating elements, and they have distinctive style. They even work well with a dark mode add-on on Mobile Firefox.
I checked out Guardian.co.uk (assuming that's what you meant), and yes, it is a pretty well designed site that works great on and doesn't seem to even distinguish mobile vs desktop users. But still, this is about the only mobile site I couldn't find anything wrong with. This isn't the typical 99% site.
This is not one of those.
All you needed to do then, and today, is make sure your HTML is valid and that you don't break things on purpose ("this site optimized for MSIE1.0" type of stuff) and your site will forever be mobile and any-other-html-rendering device friendly.
- drop 99% of the JS (PWA, lazy-loading, infinite scroll, jquery, you don't need any of them for a webpage), convert the remaining for 1% to vanilla js and use it as progressive enhancement.
- use EM or % as layout width/height
- inline css, js, and svg
EDIT
- no webfonts!
The only thing that'll remain as an issue are tables wider, than viewport, on mobile.
My site: https://developers.google.com/speed/pagespeed/insights/?url=...
But yeah, lazy-loading, infinite scroll, etc., are all designed to cover up design flaws that impact performance. I think lazy-loading can be potentially done right, but almost none of us do anything right.
> use EM or % as layout width/height
Why? EM/REM is good for handling font sizes, but for anything else it may not make sense and a custom font setting in the browser can break layouts if the size of boxes are based on font sizes. PX is perfectly adequate for layout, and is actually a relative unit(PX !== hardware pixel). Same for borders, padding, margin, etc. Even REM is better than EM for most cases. People who adjust the font size in their browser don't necessarily want their layout to change and potentially degrade as a result.
> inline css, js, and svg
Can be a good idea, especially if you can somehow identify the CSS used on page load and discard anything nonessential. Though maybe HTTP/2 makes inlining obsolete. IDK
> no webfonts!
Thank you! Web fonts are perfectly sufficient in 99% of cases.
I had a lot of bad experience with px, but it is true that for borders it's the only reasonable choice.
REM is not that well supported, especially in awkward browsers (Dillo, for example).
Imo EM is nicer for padding/margin; it keeps the text/layout ratio even if the font is resized, unlike px.
But point taken, it cannot be used as the only unit.
I hadn't seen the old Google logo in years: http://www.drtsolutions.com/drtqueries.htm The search widget doesn't even use an <iframe>. Just a plain <form>.
Sorry, not sorry.
https://www.lingscars.com/
My favorite bit was the rollover buttons that used a Java applet to do so.
That is what I miss the most about the old web. We wanted to build something better by sharing knowledge. And for a while we did. Then mainstream came and corporates took over.
https://www.seamonkey-project.org/
https://www.wonder-tonic.com/geocitiesizer/
"Make Any Webpage Look Like It Was Made By A 13 Year-Old In 1996"
Time for a smooth, GPU accelerated 60+fps marquee implementation?
I'm sure a lot of you already know this easter egg, but if you search "blink tag" in Google, Google makes all the blink tags actually work (using JS of course but still)
https://www.google.com/search?q=blink+tag
But I use CSS, not JS.
The big problem was always Accessibility-related semantics. Websites laid out in TABLEs were often quite confusing to screen readers, as TABLE has a lot of supposedly important semantics in how it should be read/engaged with and using a TABLE for layout follows none of them. (What does a table header mean in a layout? Most layouts wouldn't have good headers. How do you describe what a table column is supposed to be for without a column header?) It's a shame that narrative was never clear enough that Accessibility was always the big reason TABLEs were considered a Bad Idea for layout.
(Speaking of downloading a megabyte of data, I recall how long I felt that a 1.44 MB floppy was the best restriction for the size of an entire website. If it was bigger than a floppy you were probably doing something wrong. I stopped counting floppies a long time ago; that person might be ashamed at how many floppies a typical website downloads these days.)