It's a satirical tweet, but I find it interesting the tweet is 6 year old and reflects how little has changed in website design. I’m undecided if this a good or bad thing.
For startups and SaaS websites this layout template is instantly recognisable. Is it a cookie-cutter approach to website design? Or a boring but reliable layout template?
I recently started designing t-shirts aimed at gamers. It's not art, more like graphic design. I uploaded the designs to a Print on Demand (POD) service. Sales so far are zero (which is what I was expecting) but the main movitation was to improve my design skills.
What I would love to hear from anyone (especially gamers) is:
Are these designs any good or likeable? Or something you would never wear?
The game controllers are not meant to imitate actual game controllers (e.g. Xbox) but are a stylized interpretation. But I wonder if gamers prefer a copy of their favourite console controller instead of something more generic or abstract?
And for those interested in more detail...here's what I've learned so far designing t-shirts:
- Keep it simple: A design that is easy to understand and be seen from a distance can work well.
- Choice of type matters: This makes a big difference. I haven't mastered this by a long shot. Still learning and practising.
- Colour is important: finding a pleasant-looking combination of appealing colours is really hard.
Fun fact: The design with the wording 'Ready to play' was rejected by the POD service. I later discovered it was because it is a trademarked phrase!
Thank you everyone for your encouraging comments. As with any product, there's always the fear of "if I build, will they come?" But without building, I'll never know. So time to get building :-)
I hope it's OK to piggyback on this question and ask: are there any opportunities in designing (and selling) website themes, particulalrly non-Wordpress themes?
Many replies here say don't offer design. But presumably, even when you're developing the backend, you need to reach for a front-end design or template - either free or for sale. The market for HTML/CSS themes is completely saturated though - is it fruitless to pursue this avenue?
You might not need a static site generator for a single page website. Why not simply author it directly in HTML and CSS? It might actually be faster (and simpler) to code by hand.
Here are two dummy test pages I made a while ago to see if I could create a fast-loading, fairly lengthy text page for slow mobile connections.
There is no table of contents, but you could add that as a simple list of links to the top of the page.
> A blog is really fast if you don't put anything but text in it basically
Here's a dummy test page I made a while ago to see if I could create a fairly lengthy, fast-loading text page for slow mobile connections. It's hosted on a cheap shared hosting plan, so it may well fall over (or not!)
The image at the top of the page hasn't been optimized (about 40kb), however I do think aesthetics are important in page design and I'm against reverting to a plain HTML look with no CSS styling. The test pages above are plain looking but, I hope, reasonably pleasant to look at. (The custom font version looks nicer in my view than the no font loading version, but of course it adds a bit of extra page weight).
Text articles are probably the most widespread type of content on the web. Most web sites are not web apps. But many developers want to re-construct web sites into web app architectures even when there's no benefit to the end user.
I posted the links below on a previous discussion about AMP. They are two examples of basic, javascript-free web pages with text content. There's about 2500+ words on these test pages, but the page weight is still much smaller than, for example, a medium article with one tenth the number of words (250).
Try loading them on your mobile on a 3G (or slower) connection. Do they load fast or slow?
Version B could probably be optimized here by not loading two very similar fonts.
You can also try loading the font locally first, to avoid the download if it's installed on the user's system.
Finally, unicode-range lets you avoid the download completely if that character isn't included on the page. Not a likely outcome on an English page, but a good practice regardless.
Webfonts are tough to optimize, but not impossible. Right now there's solutions of using Javascript to background the font so it's non-blocking (eg. loadCSS[1]), but it's not ideal when trying to keep overhead down. The situation should improve once font-display[2] becomes standardized.
For what it's worth though, I find Version B looks much nicer.
Version B has two different font weights from the same family: Regular and Medium/Semi-bold. Version A relies on the fonts already installed on the user's computer.
Dropping the semi-bold font weight would save approx 23k, but having a regular and bold font weight felt like the minimal styles needed to support the page.
Dropping the header image would save 40k. (Note: the header image hasn't been optimised using something like the HTML srcset attribute which can load different picture sizes for different devices).
Do we really need Instant Articles (Facebook) and AMP (Google) when we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?
I feel that many web developers don't realise that simple HTML and CSS is often all you need to make clear, fast loading pages. No complicated tricks or techniques required. You can make the page reasonably pleasant in appearance too.
Think of the sites you often visit: news stories, blogs, magazine-style sites, discussion sites. These are mostly text, not web apps.
I hope I'm not hijacking this thread, but I'd like to ask if readers find the web page links below fast to load on their mobile phones? They don't use AMP.
I created the pages below as a test because I was (and still am) frustrated by the slow page-loading speeds when using my phone with a 3G connection.
The page links below represent a common article/blog/report style of page. There's about 2500+ words on the page.
The page content is CC licensed but the pictures from the original synopsis are not included despite the references in the text (since this was just a test)
Okay but let's be realistic-- you are not a major publisher trying to make money off these pages. You can say "yes my page loads in 100k and 300ms until DOMContentLoaded" all you want, that doesn't change the fact that when you slap a couple of pieces of advertising on there, it's going to slow down.
To give you an idea-- the New York Times page without any advertising on it is 2MB and has a DOMContentLoaded event at 1.29s, approximately 1 second slower than your page. With advertising, it is 3.9MB and 1.82s.
When ad networks are able to run without almost 2MB of Javascript, then we can talk about how AMP isn't needed.
> you are not a major publisher trying to make money off these pages.
Hate to break it to you, but major publishers aren't making any money of the AMP'd version of their pages - most of the monetization is stripped out, and readers aren't even actually on their site so they won't stay and click around.
The spec for amp specifically has an "amp-ad" tag for displaying ads. There are multiple ways they can be shown in an AMP page. The nice thing about AMP ads is they will not cause the page to change layout/flow as they load. I believe a size must be declared for ads to prevent bad behavior.
I didn't say they couldn't show ads, but basic ads aren't the only way that these places monetize. Trackers, 'you might also like' panels, etc all feed in to the overall monetization strategy. A couple of amp-approved ads on an amp-page don't necessarily make up for all that...
I'm not trying to avoid anything. As a user I don't even get a choice for AMP or no AMP. In fact, I changed my search engine on my phone to DuckDuckGo specifically to get rid of AMP pages.
As a dev at a major publisher I can confirm that we are making money off these pages, and readers are actually clicking on more recirculation links. The monetization isn't stripped out at all, it's just all sandboxed in iframes.
^^^And THAT RIGHT THERE is why I load the asynchronous Adsense script at the very bottom of my pages, after everything else, and why I load my core JavaScript synchronously, just before that, so it can schedule key tasks before getting swamped with third party guff.
I mean, sure, Adsense loads asynchronously and Google claims it won't slow your page loads, but once it starts loading advertising assets and scripts it's the Wild West. Some - not all, by any means, but some - of those third party scripts are extremely badly behaved and, yes, they do measurably slow your page load down.
page without any advertising on it is 2MB and has a
DOMContentLoaded event at 1.29s
With advertising, it is 3.9MB and 1.82s
This does not support your core argument about ads being the issue.
The ads load in 602ms.
The page loads in 1290ms
The ads are 1.9MB of data
The page is 2MB
Yes the ads are very heavy. But how are the ads slowing the page down exactly? The page is already INCREDIBLY slow without them.
Only ~30% of load time is spent with displaying the ads. The other ~60% is what ever brain damage the NYT web team cooked up. If anything you are enforcing parent poster's point.
I doubt the payload is the problem in most cases. The ads load asynchronously, in most cases, and cause other types of performance issues. When an ad loads and causes your scroll position to be lost, or when the ad takes over the screen and can't be closed, or when you get a malicious ad that starts running JavaScript that starts opening alerts and redirects you, all of these things simply don't happen with AMP.
I disagree with that. AMP pages load and work for me without fail. Most non-AMP news sites are unreadable on my phone. Saying it adds a "layer of suck over an already sucky experience" doesn't give AMP nearly enough credit.
How do you find the URL of an AMP page? What's the point of it if I can't? Sharing content from mobile is near impossible without also tracking the sharing.
I mean, really, that's most of AMP: a restriction on a bunch of elements that may slow things down and a bit of special mark up so things can be further accelerated.
If most websites actually did load quickly, then I don't think AMP would have a reason to exist. But if most websites can't manage to slim down their bloat, then one potential answer may be to take away some of their toys (and I'm not saying it's the right answer, just a large part of AMP).
Ok, so the solution is to create a standard subset of elements and create an open tool to test your site against the standard. If your page meets the requirements it gets the pagerank boost. If it doesn't meet the requirements somewhere then it points out what you need to change. No need for AMP.
That would work (and personally I would prefer if AMP went in that direction) but it would be merely fast instead of crazy fast because apparently prerendering is only possible if you use the Google CDN.
Why? Chrome has been prerendering pages on search results for years. The only thing I could think of that would make it slower is that you may need to do a DNS request for a different domain, where google's domain is already resolved. (And google probably has a better CDN.)
google could have opted to create a standard that matches the amp standard, but not host the pages, and not put a "X" bar at the top, and not create new urls. they could have put the lightning icon on the serps next to all pages that are fully compliant with the standard.
the difference in speed between google-hosted amp and what i suggest above would be minimal.
the reason google didnt do it this way is because amp is not about speed. speed is just the thing they pitch to you to get you to look past all the negative aspects of the system.
Google could have, indeed. We were aiming at instant loading, though, and for instant loading we needed to do pre-rendering, and the only known way to do that does not allow for changing the origin (has to stay https://www.google.com).
We are working on a few ways how to both make access to the base URL easier and how to eventually even get the right URL in place.
We're not talking about developer/technical blogs, which are generally very lightweight, and the person making it likely takes pride in things like efficiency. Your typical content publishing platform on the other hand, is a giant mess of wordpress plugins, tracking, ads, and scripts that pull in other scripts that pull in other scripts. Is it efficient from a technical perspective? No, but it gets the job done for them. AMP is a solution that makes it dead simple for these shops to get a reasonable load time for their content on mobile, which translates to less time spent, which at the end of the day is more important to them.
The problem is that their framework is too big and bloated. Your suggestion is to have them add another layer on top of that, rather than remove the bloat?
> we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?
Sure, but news sites don't. That's the problem. They're loaded with bullshit that makes them mostly unreadable on many devices, screws with your scrolling, and takes insane amounts of bandwidth. The problem is that these news sites are fiscally incentivized to make their experiences bad. The more crap you load, the more money you make.
The hook here is that Google gives priority to AMP pages. "Make your page be provably not terrible and we'll rank you higher than your competitors" is a really juicy proposition, and it makes the user (who just wants to read their news) happier. To a news site, you're faced with the decision of having more revenue with a terrible UX or potentially less revenue with more traffic.
Version B was noticeably slower for me on desktop, but still 100% okay in my book. Version A was near-instant. My eye caught that the image didn't magically appear fully loaded, but after a split second loading was complete and the page (and layout) look great!
Thanks for trying out these test pages! When I created them, I tried loading them in different locations on my phone. Surprisingly, even in busy city-centre locations (using 3G), the pages weren't always loading instantly - but they were fairly fast, enough to feel usable.
Anecdotally, this article for me took about 5 seconds after loading the text to apply its CSS and fonts, which was kinda jarring when reading. I don't need an exotic font to read basic content. I'd most like a simple lightweight site, but I'd take AMP over this site's clunkiness.
Version A was excruciatingly slow. Version B was very quick.
I wonder if original dns resolution wasn't to blame... or either load or lack of a recent one on your server. I know I'm a little late to the party in this thread.
> Do we really need Instant Articles (Facebook) and AMP (Google) when we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?
Can you suggest frameworks that help me do this automatically? Please no, raw html. I daresay that those would recommend developing without frameworks have no experience maintaining other people's projects.
We need it like we needed "use strict" in JS, which is to say not really, but it really helps. I think of AMP as "HTML Strict", a means of enforcing the rules and practices necessary for faster web sites.
If you need to support older browsers without Flexbox, another option is to use a tiny (less than 1kb) CSS grid system called Pocket Grid.
The grid system lets you position blocks of content side-by-side similar to Flexbox, and blocks can wrap to another line when there isn't enough space. It's not an equivalent to Flexbox, but for some types of layouts it could be used as a possible fallback.
Pocket Grid has been around since 2013, it's a shame it hasn't gained more attention:
Take a look at Pocket Grid. It's not a framework, but a tiny responsive CSS grid system. Given that many websites are relatively simple in layout and presentation, it may be all you need. It's a shame this grid system hasn't gained more traction (it's from 2013)
For many websites, you don't need a framework. My (completely anecdotal) impression is that few web developers trim the fat from the frameworks they use. That is to say: the websites they create have many unused CSS rules and unnecessary scripts. This amounts to substantial extra KB being downloaded by website visitors even when it's not needed.
Additionally, many sites are over-engineered with excessive Javascript to render simple web pages (even when the site is not a web app).
I did look pocketgrid last year. I could not get it to behave like something like bootstrap. It would be nice if there was a simple grid that just sort of worked on all the modern mobile and desktop browsers. I am ok with not supporting IE or other browsers that have a tiny market share
For startups and SaaS websites this layout template is instantly recognisable. Is it a cookie-cutter approach to website design? Or a boring but reliable layout template?