It's 2012, HTML5 is awesome, and I'm surfing a PDF(stephanierieger.com)
stephanierieger.com
It's 2012, HTML5 is awesome, and I'm surfing a PDF
http://stephanierieger.com/its-about-the-content-stupid/
29 comments
Yes, the site itself is immediately at fault, but the author used it as an example of her point, which is that the web in its current state is pathetic.
There are plenty of little things that can make a website faster: image sprites, minified js, etc. Why don't the tools we use automatically handle this?
Why are we so focused on creativity and customization instead of standardization and ease of building? Look at the waves of designers who are crying foul over Twitter Bootstrap and trying to convince us not to use it because they realize that the demand for their services has just been cut in half!
Why are there no tools that provide the myriad of widgets we roll by hand each time? Lists, sliders, progress bars, drop-downs, calendars, etc. Well, there are. There's GWT, there clones of it for python, there's Wicket, and more. But few people seem to use them.
There's more that can be added here, but the point is the web needs much better tools, processes, standardization, and ease of programming.
We're giving people the tools to make the web a bad experience and in general that's been the end result, though we try to avoid those websites.
There are plenty of little things that can make a website faster: image sprites, minified js, etc. Why don't the tools we use automatically handle this?
Why are we so focused on creativity and customization instead of standardization and ease of building? Look at the waves of designers who are crying foul over Twitter Bootstrap and trying to convince us not to use it because they realize that the demand for their services has just been cut in half!
Why are there no tools that provide the myriad of widgets we roll by hand each time? Lists, sliders, progress bars, drop-downs, calendars, etc. Well, there are. There's GWT, there clones of it for python, there's Wicket, and more. But few people seem to use them.
There's more that can be added here, but the point is the web needs much better tools, processes, standardization, and ease of programming.
We're giving people the tools to make the web a bad experience and in general that's been the end result, though we try to avoid those websites.
Why are we so focused on creativity and customization instead of standardization and ease of building? Look at the waves of designers who are crying foul over Twitter Bootstrap and trying to convince us not to use it because they realize that the demand for their services has just been cut in half!
Well, what 'we' are you talking about? As someone who's primarily a back-end developer with some 'front-end' skills (but not necessarily design skills), I'm not at all focused on customization or creativity. Bootstrap has been fantastic, because it allows me to make decent looking sites out of the box.
If/when a project gets to the point where a) it's out of proof of concept and b) the client/team wants better visuals, then we'll bring in a designer or two, and press them to design something around the existing CSS/structure that's there (within reason).
This will piss off the UX people to no end, and in some cases, they may be right to get upset. One size does not fit all, and Bootstrap in its current form doesn't handle every situation elegantly.
What I hope to see is an evolution of Bootstrap and some similar tools crop up to address these UX/UI needs from the perspective of a web 'person' - not a designer, not a developer, but a hybrid role. A role that both understands and implements all facets of the technology (not just advises/consults, but can actually be hands on), and a role with a primary focus on the hands-on. Not photoshop/dreamweaver on one hand, and not GWT/abstractionkits on the other.
That role doesn't quite exist yet, because the tools aren't quite there yet, but as tools like Bootstrap evolve, I think we'll see this. There should be no need to 'mockup' stuff first in Photoshop if the only (or primary) end result is web, but that's still how many projects work.
Well, what 'we' are you talking about? As someone who's primarily a back-end developer with some 'front-end' skills (but not necessarily design skills), I'm not at all focused on customization or creativity. Bootstrap has been fantastic, because it allows me to make decent looking sites out of the box.
If/when a project gets to the point where a) it's out of proof of concept and b) the client/team wants better visuals, then we'll bring in a designer or two, and press them to design something around the existing CSS/structure that's there (within reason).
This will piss off the UX people to no end, and in some cases, they may be right to get upset. One size does not fit all, and Bootstrap in its current form doesn't handle every situation elegantly.
What I hope to see is an evolution of Bootstrap and some similar tools crop up to address these UX/UI needs from the perspective of a web 'person' - not a designer, not a developer, but a hybrid role. A role that both understands and implements all facets of the technology (not just advises/consults, but can actually be hands on), and a role with a primary focus on the hands-on. Not photoshop/dreamweaver on one hand, and not GWT/abstractionkits on the other.
That role doesn't quite exist yet, because the tools aren't quite there yet, but as tools like Bootstrap evolve, I think we'll see this. There should be no need to 'mockup' stuff first in Photoshop if the only (or primary) end result is web, but that's still how many projects work.
This is a very good point. Perhaps it is time to think about what a modern web truly should be.
The web has many things going for it. It's no mystery why it's so popular. It's the leading platform to share information and media with the world. It is also a platform for apps that have a unique and very powerful advantage: you can just link to an app and you can use it just a couple seconds later, everything is automatically saved and loadable from any web-connected device, and if you don't want to use it again you can simply forget about it. This is a much nicer experience compared to manually downloading and installing/extracting an app.
However, the web has many serious problems. The web originated in the early 90s as a way to browse text and images, and new things have been haphazardly stacked on top of that over time, resulting in what we have today. It is a lot trickier to make dynamic content for the web than it should be. Due to the limitations of JavaScript, its web API and the web overall, anything scripted for the web browser feels like it's a flimsy hack. People have made much software to try to make things more sane--jQuery, CoffeeScript, GWT, etc.--but they can't solve the deep architectural problems that the platform faces. The time we could be spending focusing on making cool things is lost trying to wrestle with web browsers to get them to do what we want them to do. That's a huge loss in productivity.
We would all benefit if we redesigned the web from the ground-up.
The web has many things going for it. It's no mystery why it's so popular. It's the leading platform to share information and media with the world. It is also a platform for apps that have a unique and very powerful advantage: you can just link to an app and you can use it just a couple seconds later, everything is automatically saved and loadable from any web-connected device, and if you don't want to use it again you can simply forget about it. This is a much nicer experience compared to manually downloading and installing/extracting an app.
However, the web has many serious problems. The web originated in the early 90s as a way to browse text and images, and new things have been haphazardly stacked on top of that over time, resulting in what we have today. It is a lot trickier to make dynamic content for the web than it should be. Due to the limitations of JavaScript, its web API and the web overall, anything scripted for the web browser feels like it's a flimsy hack. People have made much software to try to make things more sane--jQuery, CoffeeScript, GWT, etc.--but they can't solve the deep architectural problems that the platform faces. The time we could be spending focusing on making cool things is lost trying to wrestle with web browsers to get them to do what we want them to do. That's a huge loss in productivity.
We would all benefit if we redesigned the web from the ground-up.
Exactly right. The number of HTTP requests is ridiculous on this site. Check out the waterfall view on WebPageTest[1]; even though the files are all small, it's another connection for every single one. As ekidd said, CSS spritesheets and combining js/css is the answer.
[1] http://www.webpagetest.org/result/120528_SJ_E14/
[1] http://www.webpagetest.org/result/120528_SJ_E14/
Out of curiosity, has anyone reached out to camper and told them? It would be interesting to see if a dialogue can be started with the company to see how they would react.
EDIT - Sent em a tweet. Lets see what happens
EDIT - Sent em a tweet. Lets see what happens
Camper could fix their site by tiling all their little PNGs into a couple of large PNGs, and merging all their JS into a single file.
Or the various parties could implement SPDY or a similar technique, resolving most of the issues without adding maintenance issues.
EDIT: Really? Downvotes? Some people are a little too invested in their hackish, half-measure optimizations.
Or the various parties could implement SPDY or a similar technique, resolving most of the issues without adding maintenance issues.
EDIT: Really? Downvotes? Some people are a little too invested in their hackish, half-measure optimizations.
SPDY - Lack of browser support (Remember this is a consumer site, not a techy-i-already-use-chrome-and-firefox-nightlies site)
Similar Technique...Like what?
Downvotes were probably due to those two things "Not really providing a useful answer" (sorry if that comment offends. Just my opinion).
Similar Technique...Like what?
Downvotes were probably due to those two things "Not really providing a useful answer" (sorry if that comment offends. Just my opinion).
Firefox and Chrome stable both implement SPDY.
IE users should already be used to lack of rounded corners, full page reloads for address changes, and more things as IE's release policy causes it to fall further behind the web. Not letting them do something else won't change their already poor experience.
IE users should already be used to lack of rounded corners, full page reloads for address changes, and more things as IE's release policy causes it to fall further behind the web. Not letting them do something else won't change their already poor experience.
Firefox and Chrome both support it, ok.
IE and Safari (Vast majority of desktop computers and a good chunk of macs and IOS devices) don't...
...In fact, I have just re-read your original comment and noticed the "various parties" bit which my brain skipped over before.
My previous belief was that you were saying they should just switch the site to SPDY right now and screw anyone who doesn't support it right this moment which is obviously unworkable.
But since that doesn7t appear to be the case, i have no idea why downvotes were done (unless they made the same mistake I did).
IE and Safari (Vast majority of desktop computers and a good chunk of macs and IOS devices) don't...
...In fact, I have just re-read your original comment and noticed the "various parties" bit which my brain skipped over before.
My previous belief was that you were saying they should just switch the site to SPDY right now and screw anyone who doesn't support it right this moment which is obviously unworkable.
But since that doesn7t appear to be the case, i have no idea why downvotes were done (unless they made the same mistake I did).
If you want 100% support; just wait for the IETF to finish HTTP/2.0. It may not be the exact SPDY protocol, but it will most likely support a reasonable form of multiplexing, and I am confident all major browsers will implement it. But its probably ~2yrs away.
I have a good Internet connection into my home here in the United States (I telecommute from a home office) but I also have 4 kids. The older two have graduated to streaming video to their laptops, but the younger two still prefer choosing titles from Netflix.
When they're all streaming video, I find have the exact same problem on a desktop with plenty of resources. I think Stephanie's message should be applied several ways. We should degrade gently for underpowered devices like phones, but we should also be cognizant of the network capacity of the user.
Coming from the embedded systems world, I know what it is to count every clock cycle and every byte of RAM. I need to remember those techniques when I'm designing and implementing web applications. Thanks Stephanie!
When they're all streaming video, I find have the exact same problem on a desktop with plenty of resources. I think Stephanie's message should be applied several ways. We should degrade gently for underpowered devices like phones, but we should also be cognizant of the network capacity of the user.
Coming from the embedded systems world, I know what it is to count every clock cycle and every byte of RAM. I need to remember those techniques when I'm designing and implementing web applications. Thanks Stephanie!
Yes, Google Maps interface comes to mind every time I get reminded about this issue: "Still loading? Use the basic HTML version or click here for help"
Although I wonder if this really is the best solution.
Problems:
User has to explicitly select a change.
Once you change it might go faster, but it's no guarantee and makes you wait a longer total time to get to the first complete view.
Benefits:
It does not depend on directly measuring bandwidth (wasteful and still would take longer)
Relays information about the problem to the user and not just a bad experience.
Although, short of dynamic loading of less intensive interfaces until it ends up rendering a "basic HTML" view, I fail to see one. I haven't seen this implemented though.
Although I wonder if this really is the best solution.
Problems:
User has to explicitly select a change.
Once you change it might go faster, but it's no guarantee and makes you wait a longer total time to get to the first complete view.
Benefits:
It does not depend on directly measuring bandwidth (wasteful and still would take longer)
Relays information about the problem to the user and not just a bad experience.
Although, short of dynamic loading of less intensive interfaces until it ends up rendering a "basic HTML" view, I fail to see one. I haven't seen this implemented though.
I wrote a bit about this [1]. The basic idea is that CSS media queries, which currently just let us know about screen sizes, should also give us otherwise information like network latency and CPU
[1] http://www.createopen.com/blog/2012/05/taking-responsive-des...
[1] http://www.createopen.com/blog/2012/05/taking-responsive-des...
I agree with her. I don't go to most sites to have some 'experience', rather I am there to find certain pieces of information or to use a service. Any technology that hinders me in the pursuit of that purpose, flash intro videos being the typical example, is frustrating and annoying.
If the technology is super cool I might play with it for a while, but in the end I am skipping through trying to find what I came for originally.
This particular example annoyed me - I found it glitchy and there was no compelling reason for me to want to look at it. I had no reason to visit the site in the first place, so perhaps my opinion is not that important.
On the other hand, the designers may have done lots of testing, and determined that this design is the one which results in the most sales (or whatever). In any case, technology should never be a substitute for good user experience, not even flashy html5.
This particular example annoyed me - I found it glitchy and there was no compelling reason for me to want to look at it. I had no reason to visit the site in the first place, so perhaps my opinion is not that important.
On the other hand, the designers may have done lots of testing, and determined that this design is the one which results in the most sales (or whatever). In any case, technology should never be a substitute for good user experience, not even flashy html5.
This is the most important point: what is the site trying to accomplish? Or better, what are users trying to accomplish with the site? Presumably, the site is trying to sell shoes, and creating an "experience" around those sales might be crucial for Camper. On the other hand, such an experience may be (as in this case) an impediment.
As others have mentioned, the trick is using tools appropriately. But first you need to know for what use cases you are designing.
As others have mentioned, the trick is using tools appropriately. But first you need to know for what use cases you are designing.
[deleted]
I know this will never happen, but how great would it be if we saw a revival of Gopher for this very reason? HTML is clearly going to be for applications in the future, so Gopher could fill in the hole of "just show me the content". Again, won't happen. But I can dream. If only there were a 0-click way to convert a html site to a gophermap/text files.
People don't want to just "see the content".
If you want that, you can just fire up links/elinks/lynx; it, surprisingly, works fairly well even today.
But even the writer of the article didn't want to just see the text - she wants to see the shoes and decide which one to buy. You don't want to see a table with shoes numbers, descriptions and prices when you are shopping; visuals are important, too.
That's why noone is actually using text-only browsers.
If you want that, you can just fire up links/elinks/lynx; it, surprisingly, works fairly well even today.
But even the writer of the article didn't want to just see the text - she wants to see the shoes and decide which one to buy. You don't want to see a table with shoes numbers, descriptions and prices when you are shopping; visuals are important, too.
That's why noone is actually using text-only browsers.
She wanted to "see the content". The "content" just included images as well as text. What she didn't want was the heavy interface.
Maybe a new content type would work... "text/html" would be the application and "text/static-html" would be "just the content"? Browsers would then just have a toggle option of some sort.
Maybe a new content type would work... "text/html" would be the application and "text/static-html" would be "just the content"? Browsers would then just have a toggle option of some sort.
Replying to myself to clarify that I wasn't really being serious. Certainly it would be nice to be able to tell arbitrary web sites "no interface, just human-friendly information". But since they'd all have to implement that, it really wouldn't work better than what is already possible.
This whole thing seems like a Macromedia redux of sorts. Web devs suddenly have a bunch of new tools to play with and some of them go nuts and do stupid things we'll all laugh about in 5-10 years. Of course in 5-10 years there will be something else for short-sighted marketers to abuse...
This whole thing seems like a Macromedia redux of sorts. Web devs suddenly have a bunch of new tools to play with and some of them go nuts and do stupid things we'll all laugh about in 5-10 years. Of course in 5-10 years there will be something else for short-sighted marketers to abuse...
What about XML for content and XSLT for display? User could use a variety of XSLTs depending on constraints, viewing conditions.
Or, the designers/developers can make sensible decisions about what to include. The existing tools are fine, and provide plenty of techniques for optimizing to different viewing platforms and environments. The problem is people getting carried away with the whiz-bang stuff that's possible, while ignoring degradation. I can't imagine how XML/XSLT would be any better.
The issue isn't what format the content is in, but that it's retrieved through client-side logic rather than as part of the query response.
Also, what's wrong with HTML/CSS that is in any way resolved by XML/XSLT? I'm genuinely curious why somebody would put their content into a format with no default, well-understood display semantics.
Also, what's wrong with HTML/CSS that is in any way resolved by XML/XSLT? I'm genuinely curious why somebody would put their content into a format with no default, well-understood display semantics.
Maybe I misunderstood how the xml/xslt-paradigm works, but my idea was that you have a serverside api serving up raw data, and the display is controlled by some code on the clientside that can be easily customised. So the server could serve up something like
<shoe>
<images>
<image>foo.com/x.jpg</image>
<image>foo.com/y.jpg</image>
</images>
<description>This shoe is very advanced bla bla bla</description>
<fancyintroanimation>foo.com/intro1.swf</fancyintroanimation>
</shoe>
<shoe>
....
and the client could use the default xslt if they were happy with that, and a custom otherwise.
and the client could use the default xslt if they were happy with that, and a custom otherwise.
If you turn off Javascript and cookies, a ton of sites that serve what at least could be static content and which you don't need to log into simply stop working.
What happened to graceful degradation? Is it not agile enough to expect a server to be able to work at least minimally with any browser?
What happened to graceful degradation? Is it not agile enough to expect a server to be able to work at least minimally with any browser?
It is my belief graceful degradation got discarded when the "ditch ie6 movement" began to get full over-blown coverage.
Here's an experiment with showing "just the content" http://www.shopobot.com/shop
Online stores show so little of what they're actually selling - we wanted to try stripping out everything that isn't the products. (using shoes from Amazon as the example here)
Online stores show so little of what they're actually selling - we wanted to try stripping out everything that isn't the products. (using shoes from Amazon as the example here)
Gopher supports images.
People don't want to just "see the content".
That is presumptuous: Most users have zero choice in the matter.
That is presumptuous: Most users have zero choice in the matter.
Users have a choice: they go to another web site.
So if I like the content of site A, but not the presentation of site A, my choice regarding the presentation is to visit site B?
I think you're confused and you aren't really keeping up with the conversation.
I think you're confused and you aren't really keeping up with the conversation.
Touchy, touchy. In the context of the OP, if the user liked the shoes but not the website, she could order them on Zappos (for example) instead.
I just went on a journey through the remains of gopherspace. Thank you :)
Website is down, cache is available here:
http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...
I think the real issue here is a lack of graceful degradation on the Camper website. Built the right way, their fancy paper.js presentation thing would source whatever content it needs from within the page itself. The only excuse is laziness coupled with an unhealthy infatuation with new shiny technologies. I guess there are some bored people behind this who think anything, even a shoe catalogue, can be revolutionised. And that's fine, but they forgot about the core fundamentals of the web -- the kind I can rely on when loading up lynx and firing off a GET request to see some ... content.
Degradation wouldn't help here - her browser can cope, it just takes an age to download the contents of the web page over a slow link.
To see a "degraded" view though, I would just disable JS. Isn't this viable?
Probably not. It is often the case that a site is built entirely (read meaningfully) in JS. If one wanted to degrade gracefully without JS, one would have to have two sites: JS and Plain-Old-HTML. Now this is not possible, especially for a startup. You have a set number of resources. DRY helps allocate them. If you violate DRY with 2 sites, you're focus is going to be lost.
Now some might say that good web design was violated by make the site dependant on JS. However, as the title shows, this is 2012. My cellphone has the ability to render most JS effectively. The old adage about degrading JS is just that, old. It was in a day before ECMA Script was sanctioned or common on the browsers. It was before jQuery and the like unified the browsers.
tl;dr: JS is ubiquitous and is what the front end, and even the whole app is built on.
Now some might say that good web design was violated by make the site dependant on JS. However, as the title shows, this is 2012. My cellphone has the ability to render most JS effectively. The old adage about degrading JS is just that, old. It was in a day before ECMA Script was sanctioned or common on the browsers. It was before jQuery and the like unified the browsers.
tl;dr: JS is ubiquitous and is what the front end, and even the whole app is built on.
using a text browser at all feels quite pointless these days, as much as I like them. Even programming website (case in point stack overflow) just don't work at all without javascript and images.
>Even programming website (case in point stack overflow) just don't work at all without javascript and images. //
I just tried with Links 2.6 and it worked fine on StackOverflow.com.
I just tried with Links 2.6 and it worked fine on StackOverflow.com.
Recent versions of Links support Javascript, so that was helping. However, I've been on Stackoverflow with javascript turned off (noscript) and it is one of the few sites that still renders usable.
Irony alert:
Database overload for an article on lightweight websites.
I also find it odd that the masthead for the blog is a 737KB PNG...I don't know why you wouldn't use a JPG - at a high quality level it's virtually indistinguishable and 1/4 of the size.
It's a little pedantic, but if you're going to talk about how sites should be lightweight and then use a sizeable PNG image you're sort of opening yourself up for criticism.
It's a little pedantic, but if you're going to talk about how sites should be lightweight and then use a sizeable PNG image you're sort of opening yourself up for criticism.
They could at least run the PNG through a png compressor and shave 91kb off the size (tested on pngout) and without any loss in quality. Would save a lot of bytes over time...
The SmushIt image compressor in Yahoo's YSlow quickly became one of my favorite pocket-sized web dev tools.
She's tweeted saying that was a mistake and she'll fix it.
A good lesson though to remember before calling someone out publicly. We all make mistakes, and the author is not exempt from this rule.
Yeah, but she's a blogger and Camper is a company worth millions of dollars.
I don't expect good design from bloggers. If they say smart things, I'll read. I expect good design from people who theoretically want my money, because it's their job not to irritate me when I'm trying to pay them.
I've avoided buying products from companies who make terrible design decisions. Not even to punish them, just to avoid having to deal with the pre-product bullshit.
I don't expect good design from bloggers. If they say smart things, I'll read. I expect good design from people who theoretically want my money, because it's their job not to irritate me when I'm trying to pay them.
I've avoided buying products from companies who make terrible design decisions. Not even to punish them, just to avoid having to deal with the pre-product bullshit.
HTML5 and "fast" aren't mutually exclusive. Plenty of examples where HTML5 mobile sites are plenty fast over 3G like Quora and Asana (just two that I use often).
I don't know what you mean by "fast over 3G" but over here 3G is faster than any available ADSL plan you can get. I sometimes tether to my phone to download some contents when I'm in a hurry. I'm guessing the article is talking about sub-256kbps wifi.
3G is never meant for Live Traffic. There are latency issues and packet losses being wireless. There is no proper QOS guarantees on top of the Wireless Stack.
So never expect good skype experience or any real-time services like - Live search on 3G networks.
So never expect good skype experience or any real-time services like - Live search on 3G networks.
It's 2012, and I'm using a lousy hotel wi-fi shared by 503 guests that takes me back to 1997 connection speeds.
No wonder PDF is the solution. Sure, sites should be optimized to the fullest extent possible and probably even detect connection speeds and offer a low bandwidth version (are there libraries for this already?) when appropriate; but that's a huge amount of work (and money) for what basically are outliers (I wouldn't expect many people to browse the Campers site from a lousy wi-fi in Bangkok)
No wonder PDF is the solution. Sure, sites should be optimized to the fullest extent possible and probably even detect connection speeds and offer a low bandwidth version (are there libraries for this already?) when appropriate; but that's a huge amount of work (and money) for what basically are outliers (I wouldn't expect many people to browse the Campers site from a lousy wi-fi in Bangkok)
I am on unshared 12Mbps ADSL, not the fastest around but surely faster than 1997 connection speeds and my experience was similar. Around 20 seconds for the initial loading and 5-10 for each collection. I am glad I wasn't actually looking to buy shoes and just checking the times the content took to load so I wouldn't say this design example is a problem just for the outliers.
That wasn't my experience. It would be interesting to arrive at the bottom of the problem. I take it I'm being served a different page than you are, maybe due to location (I'm not on the US, but then, neither was the article author)
To be fair, the blogger is pointing to the Camper website "Lookbook" which in this industry is more of a "vanity" type display. It's meant to be a little creative and in this case it's extremely creative and extremely heavy.
If the author of the blog just wants to look at some shoes, then the Camper website catalog is probably where she wants to be:
http://www.camper.com/en/eshop/productos.xhtml?type=W
I'm confident that if you looked at the Camper website daily visits a majority of browsing/shopping (90%+) will be taking place through the Catalog and not through the Lookbook.
If you take a minute to view the homepage HTML you'll notice that there is only 2 links through to the Lookbook and that is only accessible after hitting the arrow down / MENU menu item and then clicking through the SHOES menu and submenu items (which itself is a pretty unintuitive element).
The author brings up some good points about the Lookbook, but we shouldn't pretend that the website is using it as its main interface to the products.
If the author of the blog just wants to look at some shoes, then the Camper website catalog is probably where she wants to be:
http://www.camper.com/en/eshop/productos.xhtml?type=W
I'm confident that if you looked at the Camper website daily visits a majority of browsing/shopping (90%+) will be taking place through the Catalog and not through the Lookbook.
If you take a minute to view the homepage HTML you'll notice that there is only 2 links through to the Lookbook and that is only accessible after hitting the arrow down / MENU menu item and then clicking through the SHOES menu and submenu items (which itself is a pretty unintuitive element).
The author brings up some good points about the Lookbook, but we shouldn't pretend that the website is using it as its main interface to the products.
I don't know if the camper website is differentiated by region, or if I'm looking at a totally different website (http://www.camper.com ?) but I'm not seeing what she's seeing at all. I see a pretty standard e-commerce website with no "loadings" at all.
It's pretty image-heavy, for sure, but that's to be expected when how else are you supposed to look at shoes?
It's pretty image-heavy, for sure, but that's to be expected when how else are you supposed to look at shoes?
I see what she is seeing. http://www.camper.com/en/lookbook
The slowness has nothing to do with connection speed! I'm on blazingly fast Optusnet Cable Internet in Australia, and it's still incredibly slow on my (fairly recent) Asus laptop.
Bloody hell, I am on super-fast Japanese broadband and that still took about 10 seconds to load.
Oh yeah, I do see that. But if you just click "Men" (or "Women") then you don't get any of that... which is what I would've done had I been looking for actual shoes.
> I saw some nice shoes today at the mall and want to know if they’re available back home (because i’ve learned from experience that region-blocking also applies to shoes).
Region blocking applies to shoes?
Region blocking applies to shoes?
[deleted]
There's really no reason for that camper app to load so slowly. Rendering the initial screen then loading additional assets in the background with a prioritized queue could probably cut the load time by 90%.
> There's really no reason...
Well, no. Of course not. It's not at all about the technical feasibility, or even the ease, of delivering content up front. The web first began with the ability to deliver content up front and it's remained a viable option all long.
The continuing problem is that people (CEOs, designers, developers, et al) get sidetracked and forget what their site is supposed to be doing. They forget what their customers or prospective customers actually want to do: get information; use a service; buy stuff.
Well, no. Of course not. It's not at all about the technical feasibility, or even the ease, of delivering content up front. The web first began with the ability to deliver content up front and it's remained a viable option all long.
The continuing problem is that people (CEOs, designers, developers, et al) get sidetracked and forget what their site is supposed to be doing. They forget what their customers or prospective customers actually want to do: get information; use a service; buy stuff.
It's 2012. Start caching your database queries!
(Looks like the website's database connection has maxed out)
(Looks like the website's database connection has maxed out)
The Camper site is, like many other sites on the web, a bit over-produced. I would much rather have a clear layout and fast loading product pages than a fancy animated-just-for-kicks "experience" that starts to annoy after the first 30 seconds.
It's never a problem with the technology, it's a problem of misuse of the technology and bad design.
[deleted]
For some reason I thought this would be about PDF parsing on the client -- actually it's just somebody complaining that some eCommerce site takes so long to load that it's faster to download and read their PDF brochure offline.
Who cares?
Who cares?
Actually, when I read the headline I thought it was going to be about websites who make you download PDFs to read what could easily be presented in HTML as well (restaurants always seem to have PDF menus, for example).
I thought it would be about pdf.js[1] or something similar.
[1] http://mozilla.github.com/pdf.js/
[1] http://mozilla.github.com/pdf.js/
I care. I make websites and this article made me think some more about page weight vs other trade-offs.
I'm not sure what your comment has added to the debate.
I'm not sure what your comment has added to the debate.
> I'm not sure what your comment has added to the debate.
You're entitled to your opinion. But if your job is to make websites you shouldn't need a random post on a random blog to think about page weight...?
You're entitled to your opinion. But if your job is to make websites you shouldn't need a random post on a random blog to think about page weight...?
Sigh. Of course I think about page weight and a 100 other aspects of my craft. Listening to other people's thoughts is valuable in weighing up all the different priorities that compete for my attention.
So let me get this straight. You're interested $100+ shoes but prefer substance and functionality over style only when it comes to the website that sells them?
I only buy $100+ shoes. High quality shoes are so much more comfortable and long-lasting than their cheaper counterparts that their performance and usefulness more than makes up for the higher cost.
I only buy < $40 shoes and I've bought maybe 2 pairs in the last 4 years. High quality shoes are definitely more comfortable and long-lasting, however high price != high quality, even if the marketing and branding says so.
You buy $100 shoes because of style and brand. And this price tag does not always mean quality. There are plenty of expensive brands that fall apart under everyday usage.
You buy $100 shoes because of style and brand. And this price tag does not always mean quality. There are plenty of expensive brands that fall apart under everyday usage.
I bought some Vibrams some weeks ago (> $100) and they are the best shoes I ever had, a small change of lifestyle. Don't overgeneralize on that, the topic "shoes" is very broad, as is "education".
I got some Vibrams around Christmas and have been wearing them solidly for about 2-2.5 months (since the weather warmed up). The harder layer of rubber has already worn through on the heel, exposing the softer layer. I'm not so sure I'll be getting another pair.
You might consider changing your walking style. Children most often walk middle-footed or even forefooted when barefoot, and this is considered the most natural way of moving. Setting down the rear end of the foot before lowering it completely is a necessity when wearing normal shoes, but it's not natural. Before I adapted fully to the Vibrams my soles even started burning on the heels when I ran longer distances. I read that it's best to just set down the whole foot plainly (or forefoot first) when walking/running with Vs.
snarky blogger underwhelmed by website after patiently waiting thru load screen. news at 11
I ended up buying a camper shoes.
[deleted]
It's web developers that are responsible.
It's a little like advertising perhaps. Advertising has become more of an art form than a tool. Awards given for achievement in creating ads are based on the perceived artistic value of an ad, not on its market effectiveness.
Web development is viewed as an art form by web developers. The web is not a tool to them. It's a canvas.
But the reality is that for many users in many cases, the web is a tool. They just want to accomplish some task, and they are not going to pay attention to artistic value.
Maybe a good example is Amazon. Many web developers criticise the site's design. But Amazon is doing just fine. Because users do not visit Amazon for an "experience". They visit it to buy things.
Maybe there should be two versions of every website: 1. an artisitic one aimed at "user experience" where the developer could display their design skills and 2. another aimed at getting some task(s) done, quickly and efficiently. The latter might follow some universal standard. No thinking involved in its "design", just following a spec.
The user could choose. The problem for the author of this blog post was she had no choice.
It's a little like advertising perhaps. Advertising has become more of an art form than a tool. Awards given for achievement in creating ads are based on the perceived artistic value of an ad, not on its market effectiveness.
Web development is viewed as an art form by web developers. The web is not a tool to them. It's a canvas.
But the reality is that for many users in many cases, the web is a tool. They just want to accomplish some task, and they are not going to pay attention to artistic value.
Maybe a good example is Amazon. Many web developers criticise the site's design. But Amazon is doing just fine. Because users do not visit Amazon for an "experience". They visit it to buy things.
Maybe there should be two versions of every website: 1. an artisitic one aimed at "user experience" where the developer could display their design skills and 2. another aimed at getting some task(s) done, quickly and efficiently. The latter might follow some universal standard. No thinking involved in its "design", just following a spec.
The user could choose. The problem for the author of this blog post was she had no choice.
> It's web developers that are responsible.
No way. It's marketing people who are responsible. Obvious example: http://www.dustincurtis.com/dear_dustin_curtis.html
At the level that Camper (or Amazon) is operating on, the marketing department holds all the cards when it comes to the web site. The web devs mostly decide how to implement, but they're operating at the behest of marketing.
No way. It's marketing people who are responsible. Obvious example: http://www.dustincurtis.com/dear_dustin_curtis.html
At the level that Camper (or Amazon) is operating on, the marketing department holds all the cards when it comes to the web site. The web devs mostly decide how to implement, but they're operating at the behest of marketing.
In general, do marketing people know how to create websites?
If not, how can they even know what is possible to create using HTML, CSS, etc.?
If the answer is "they look at what the competition is doing," then how did the marketers at the competitor know what is possible?
It has to start somewhere. Who was behind the web back in 1993? Marketing departments? Are marketers the ones who know what can be done with HTML, etc., and what cannot?
If a marketing department asks a web developer to implement something that the developer knows will be an annoyance to end users, and then he decides to tell them it is not possible, does the marketing department not accept this answer? "Look, we know how to make websites, we know this can be done and we'd do it ourselves if we had the time, but we're busy doing marketing. Either you do your job and build this site as we ask, or we'll find someone else."
So, at some stage, some web developer somewhere makes a decision.
I remember reading the confession of a talented developer who wrote, using mini scheme, stealth malware to serve pop-ups. His skills were so good that he could disable all competing malware; the competition was helpless. The NY Attorney General later shut down his employer on consumer protection grounds. The developer was not typically an author of malware, and knew what he was doing was wrong, but his excuse for working with this outfit was that he needed a job.
Without that developer making a choice, the malware company would never have known it was possible to do what they were able to do with the help of this particular talented developer. The use of mini scheme, self modifying code and disabling all competing malware were not in his "job description". He showed them what was possible. And surely they loved him for it. But how about the users infected with the malware, who had to see his employer's pop-ups every day with no way to "turn it off"? What would they think of his work?
Just something to think about.
If not, how can they even know what is possible to create using HTML, CSS, etc.?
If the answer is "they look at what the competition is doing," then how did the marketers at the competitor know what is possible?
It has to start somewhere. Who was behind the web back in 1993? Marketing departments? Are marketers the ones who know what can be done with HTML, etc., and what cannot?
If a marketing department asks a web developer to implement something that the developer knows will be an annoyance to end users, and then he decides to tell them it is not possible, does the marketing department not accept this answer? "Look, we know how to make websites, we know this can be done and we'd do it ourselves if we had the time, but we're busy doing marketing. Either you do your job and build this site as we ask, or we'll find someone else."
So, at some stage, some web developer somewhere makes a decision.
I remember reading the confession of a talented developer who wrote, using mini scheme, stealth malware to serve pop-ups. His skills were so good that he could disable all competing malware; the competition was helpless. The NY Attorney General later shut down his employer on consumer protection grounds. The developer was not typically an author of malware, and knew what he was doing was wrong, but his excuse for working with this outfit was that he needed a job.
Without that developer making a choice, the malware company would never have known it was possible to do what they were able to do with the help of this particular talented developer. The use of mini scheme, self modifying code and disabling all competing malware were not in his "job description". He showed them what was possible. And surely they loved him for it. But how about the users infected with the malware, who had to see his employer's pop-ups every day with no way to "turn it off"? What would they think of his work?
Just something to think about.
> how can they even know what is possible to create using HTML, CSS, etc.?
Anything is possible. It doesn't mean a particular idea is good (see: the topic website), but anything is certainly possible.
> It has to start somewhere. Who was behind the web back in 1993? Marketing departments?
For big companies? Yes.
> Are marketers the ones who know what can be done with HTML, etc., and what cannot?
Implementation is beside the point. Even if the Camper "experience" in the original link loaded quickly and was implemented perfectly, it would be bad.
> If a marketing department asks a web developer to implement something that the developer knows will be an annoyance to end users, and then he decides to tell them it is not possible, does the marketing department not accept this answer?
This is the difference between a good marketing department and a bad one. The good ones will take the feedback and the bad ones won't. It's also the difference between a good organization and a bad one -- if the org makes it a habit not to talk to engineers until the idea has gone through revision after revision, UX, etc, then there's too much inertia to overcome (say, 3 months of designing, UX development, intended to be launched in tandem with a meatspace campaign, as an example).
For giant companies, the web site is a piece of their action, and often times not the largest piece. The web team (the ones who implement) are pinned to the timelines of other rollouts (in-store campaigns, billboards, magazine ads, tv ads, and so forth). So while a certain idea might not be best, there may not be time to change it -- or (consider this) the web experience might not be the most important to a company that does 80% of their volume in meatspace.
Thinking that the web site & web team should be the gatekeepers of customer experience in a multichannel business that isn't focused online is a myopic view. In spirit I'm right there with you dude, but in practice (can you tell I've worked at giant companies?) it doesn't work that way.
Anything is possible. It doesn't mean a particular idea is good (see: the topic website), but anything is certainly possible.
> It has to start somewhere. Who was behind the web back in 1993? Marketing departments?
For big companies? Yes.
> Are marketers the ones who know what can be done with HTML, etc., and what cannot?
Implementation is beside the point. Even if the Camper "experience" in the original link loaded quickly and was implemented perfectly, it would be bad.
> If a marketing department asks a web developer to implement something that the developer knows will be an annoyance to end users, and then he decides to tell them it is not possible, does the marketing department not accept this answer?
This is the difference between a good marketing department and a bad one. The good ones will take the feedback and the bad ones won't. It's also the difference between a good organization and a bad one -- if the org makes it a habit not to talk to engineers until the idea has gone through revision after revision, UX, etc, then there's too much inertia to overcome (say, 3 months of designing, UX development, intended to be launched in tandem with a meatspace campaign, as an example).
For giant companies, the web site is a piece of their action, and often times not the largest piece. The web team (the ones who implement) are pinned to the timelines of other rollouts (in-store campaigns, billboards, magazine ads, tv ads, and so forth). So while a certain idea might not be best, there may not be time to change it -- or (consider this) the web experience might not be the most important to a company that does 80% of their volume in meatspace.
Thinking that the web site & web team should be the gatekeepers of customer experience in a multichannel business that isn't focused online is a myopic view. In spirit I'm right there with you dude, but in practice (can you tell I've worked at giant companies?) it doesn't work that way.
If you're with me in spirit, I take that to mean I'm not "wrong", I'm just unrealistic, a dreamer, etc.
I think web developers have a lot of power over how the web operates. Much more than marketing departments.
In the spirit of making money, I'm right there with you. Web developers have to eat.
But to think the matter of the web's usability, or unusability (what the blog post described), is out of their hands, and solely in the hands of marketing departments, I don't buy it. Marketing has the budget, they do not have the skills, or even the knowledge.
I see numerous examples year after year that show that both large and small companies do not have the first clue how stuff works or what the implications are on end users. Developers present them with a proposition and the company writes a check. When some egregious practice comes to the attention of the press, the companies often have no idea what they were even paying for -- they do not understand what was being done.
One need only look at SEO and the types of websites it produces. It's quite a stretch to try to hold marketing departments responsible for this state of affairs.
I think web developers have a lot of power over how the web operates. Much more than marketing departments.
In the spirit of making money, I'm right there with you. Web developers have to eat.
But to think the matter of the web's usability, or unusability (what the blog post described), is out of their hands, and solely in the hands of marketing departments, I don't buy it. Marketing has the budget, they do not have the skills, or even the knowledge.
I see numerous examples year after year that show that both large and small companies do not have the first clue how stuff works or what the implications are on end users. Developers present them with a proposition and the company writes a check. When some egregious practice comes to the attention of the press, the companies often have no idea what they were even paying for -- they do not understand what was being done.
One need only look at SEO and the types of websites it produces. It's quite a stretch to try to hold marketing departments responsible for this state of affairs.
Anyone else noticed how unbearable Javascript has made the internet on older browsers?
Google on an iPhone 3G is utter pain
Any Tiger PowerPC Mac is utterly painful because browser JS engines have got so much better that we throw way too much for older browsers to cope with at them.
Google on an iPhone 3G is utter pain
Any Tiger PowerPC Mac is utterly painful because browser JS engines have got so much better that we throw way too much for older browsers to cope with at them.
Should we get off your lawn, too? ;)
I like the idea of a world that dynamically responds to you better.
Are you on a speedy networked desktop? You get the bells and whistles version. Are you own a tablet with less bandwidth? We note this, and load the appropriate version. Are you on a mobile phone on the move? We load the mobile edition which is about efficiency and speed. The user doesn't need to make decisions, but the site architect should be seamlessly making them behind the scenes.
Also, I'd love it so all versions to have the same content, optimized for all homes. If I visit another mobile/tablet site that reduces content for "my convenience" I will start punching web developers. :)
Are you on a speedy networked desktop? You get the bells and whistles version. Are you own a tablet with less bandwidth? We note this, and load the appropriate version. Are you on a mobile phone on the move? We load the mobile edition which is about efficiency and speed. The user doesn't need to make decisions, but the site architect should be seamlessly making them behind the scenes.
Also, I'd love it so all versions to have the same content, optimized for all homes. If I visit another mobile/tablet site that reduces content for "my convenience" I will start punching web developers. :)
Maybe if Stephanie's site was lighter weight it'd still be up and running :P
The Chrome developer tools show 202 HTTP requests, including tons of tiny images, and many non-minified JavaScript files. And there's only about 500k of data, so it's not really a bandwidth problem unless you're on an EDGE connection or something horrible like that.
The big bottlenecks here are round-trip latency and the maximum number of parallel requests made by the browser—if a round trip ping takes 250ms, and you can make 6 requests at a time, then it will take you a minimum of 8.4 seconds to load the page, no matter how big your pipe.
For the sake of comparison, the main Hacker News page takes 6 HTTP requests to load. A Google search results page takes 22.
Camper could fix their site by tiling all their little PNGs into a couple of large PNGs, and merging all their JS into a single file. If they got their file count under 25, they'd load quite quickly.