Related
I'm excited about the rel="preload" property, because it looks like it can help speed up page render times.
The use case is a web page with a large image above the fold. Right now, Chrome doesn't start downloading the image until after fetching jQuery (a fairly heavy file). With preloading enabled, they download in parallel.
But I'm reading conflicting reports about whether I should use preload for things that are in visible HTML elements elsewhere (as opposed to things made visible by user interaction, like a dropdown menu).
This post seems to recommend not preloading:
When not to use preloading:
When the asset is referred to somewhere else on the same page.
When you're not sure the user will actually require that asset. Like on a page visitors only go to 3% of the time.
While this one seems to indicate it was really helpful for a similar situation on the Financial Times website:
When the Financial Times introduced a Link preload header to their site, they shaved 1 second off the time it took to display the masthead image...
So which is it? Should I provide an early "hint" to display the always-shown, above-the-fold image? Or should I just let the browser get to it in the usual order?
I think that in cases involving performance optimization, you really want to create an A/B test to determine which one you should do. There really is no cookie cutter answer for image preloading that applies to everybody as a best practice.
One of the biggest tenets of a favorite book of mine, Lean Enterprise, is use to A/B tests to prove or disprove a HIPPO (highly paid person's opinion). Certain opinions carry a lot of weight, both in your organization and on the internet. Because of their importance and reputation, their opinions veer towards the realm of fact, even though it may not be.
The practice of measuring performance empirically is also touted by another book I love which deals with performance tuning - Code Complete 2nd Ed. In that book, McConnell gives several code examples where you would expect one piece of code to be optimal, but in fact, it performed poorly (see chapters 25 and 26). One of his key points is that you should always test a performance optimization. If it isn't worth testing, it isn't worth writing the "highly performant" code in the first place. McConnell's premise doesn't just apply to his low level coding examples, but to high level decisions such as preloading images above the fold as well.
I can also attest to the importance of A/B testing at a professional level. I used to work on Amazon's SEO team and we A/B tested everything. The fact of the matter is that you never really know how customers will respond to something. Nobody can predict customer behavior - not even Jeff Bezos - and you really need to back up your hypothesis with real data to prove or disprove the validity of what you're doing.
Even though you can find multiple blog articles and online sources discussing whether preloading is better or not, you don't really know whether that will work for you until you've done it. Different people have different servers with different performance characteristics and different network topologies, etc. You just don't know which way is better for you until you have the data. If you launch your A/B test and find that find that your repel rate goes up when preloading, then you know that you have to dial back your treatment and return to your control. If however, you find that customers don't get bored waiting and click through at a higher rate than before, then you have a winner and you dial up the treatment - deleting the control code entirely after a period.
I hope that helps.
The article is wrong about those statements. Preloading is used by the developer because he already knows those assets are needed on a page. Preloading is not a "hint". Prefetching is more in line with what he states, that you are telling a browser that it's possible the asset may be needed.
If an image is above the fold, then you know it will be needed, and that is exactly what prefetching is for.
Addy Osmani of Google
preload is a declarative fetch, allowing you to force the browser to
make a request for a resource without blocking the document’s onload
event.
I would use rel="preload" for images only if they are to be found in css, javascript that will led to a bottleneck in the render of the page at a later time, if user driven events will request the image and it will have detrimental impact in user experience or if you are experiencing any flows due to this large image in the rendering of the page.
I understand your image is above the fold, and if it's to be found in the source code from the beginning I would let browser prioritize what to download first.
On the other hand you could always A/B this change and see if it works for you.
I have a quick question and It might not be the right place the ask it but I hope someone can help me becuase im curious.
I'm creating a one-page website whit a lot of style (isnt designed webfriendly and uses a lot of images) this isnt a big problem because we believe we're aiming at a more design branche who most likely have kind of good pcs with a pretty ok connection to the internet and the site is sized down a lot of mobile.
But still I wonder what people recommend. my site is currently 2.2mb on loading (is there a website where you can check this btw? I just made a guess by calculating the file sizes of images etc.) I can still optimize a lot but I think going under 1mb is being a hard task. is this good enough or is there anyway who has experienced it isnt?
thanx in advance
You shouldn't worry about the size of your website (especially since you know your target audience) if the user experience doesn't suffer. However, you should optimize everything you can without sacrificing the design. Google's Page Speed might help you a lot. They even have the total size calculator you wanted. There are tons of similar tools available online as well.
Also, read this about last year's website size trends: http://www.theglobeandmail.com/technology/tech-news/bloated-web-pages-costly-for-smartphone-users/article9355125/
According to the website HTTP Archive, which regularly studies the top 10,000 most-visited sites online, the average web page now weighs in at about 1.3 megabytes, up about 35 per cent in the last year.
UPDATE
Inspired by #pwdst's comments, I'd like to add that if you want support for mobiles, tablets, etc... there's no need to sacrifice the look of the main site - you can use media queries and practically serve a different presenation to those users. Of course, you can go even further and make a different website for them (usually a subdomain).
If you use dev tools, for example in Chrome, you can see the number of requests and total transferred data under the "Network" tab. To accurately replicate the experience of your users, you should do this with an empty cache - "Incognito" or "Private" tabs can be a great way to do this in most browsers. It's also worth remembering that the experience when testing locally will be drastically different from that when the effects of latency and upstream bandwidth come into play.
Be extremely careful about assumptions regarding users if you want to maintain usability. "Good enough" is extremely contextual, it may be "good enough" for a user on a desktop, laptop or premium tablet on a solid DSL connection - but anything but on a Edge or 3G connection on a phone. Wherever possible assumptions should be backed up by analysis of user agent strings from server logs, or from analytics software such as Google Analytics. It's also worth remembering that you may have relatively few mobile or tablet requests, not because mobile or tablet users don't want to visit the website - or choose to visit using another device, but because it is difficult, slow or even impossible to use on their device of choice. This case study from an engineer at YouTube illustrates how customers were being completely excluded from the site.
In general the page should be as small as possible, and you may want to look at lazy loading in addition to optimisations, which will help initial rendering time - in fairness though your estimated size is not much larger than the internet archive average page weight of 1681kB as at January 15th this year. Don't forget that other resources can also use a lot of space - JavaScript makes up 274kB of that average - and it's not clear if you have factored that into your estimate. Aggressive use of caching will help return visitors and minimise the data transfer required in these circumstances.
I always try to consider if you can justify the page weight cost against functionality. What is the objective of visitors to your site? Does the added functionality or imagery help this sufficiently to justify the performance cost. Many performance orientated developers are now actively setting a page weight budget but this is harder for single page apps where you cannot be as granular with resources.
I would recommend using Image Pre-loading which can help your page loading times, even when its large.
With today's modern mobile phones, is it still worth programming the mobile version of your site in WML?
Most mobile browsers even a few years old can manage to do okay in regular HTML. With WML, you are obviously given more control over what is displayed and what isn't with less fear of it not working on a particular device, but today, with all the advancements in mobile browsing (iPhone, Android, etc) is it really best to go this route?
I am wondering if the best option is instead to go with an HTML4 document that has a few more bells-and-whistles than what WML can do, but not quite the glorified super-spectacular AJAXified interface that one might design for a modern desktop browser.
Yes, I know, this is objective and has a lot to do with site audiences and how far I want to extend support. To put a scope to this question, my main concern here is whether foregoing WML for HTML is going to devastate a huge chunk of my audience and leave them completely stranded.
Edit for Dr.Dredel's point: the site would NOT be used by an SMS campaign or anything of the sort. The website is an event booking site for pickup games for hockey. Some users currently browse to it on their mobile phone to sign up for different sessions.
Do both. There's no reason to ignore the browser string and display the same markup for every device. WML is simple enough that you can use template styles (which you should be using already) to provide a custom experience for all your useers, regardless of the device they use.
Those with bare cell phones will get a usable interface that meets their needs, while those with PDA phones get a nicer interface with more options, and those with the iPhone might even get the eye-candy iPhonophiles really bought their phone for.
If you can't do that, for whatever reason, go with the least common denominator to gain the greatest visibility and usage - that's what's going to make your site successfully and useful enough that you can afford to use a real templating system and move towards the ideal state. This is likely WML, although even older phones were ok with very simple HTML, it just has less control and ease of use features.
-Adam
I think the primary problem with this question is that it fails to identify what exactly it is that you're offering your users, which would instruct who, demographically, would find your site.
If your site is arrived at via SMS based links (through some global marketing campaigns) then you need to try to reach the widest possible audience, since almost all phones will allow a user to click within their SMS client and then launch whatever browser option is on the that phone.
If, on the other hand, you have a site which needs to be browsed over to manually, then there's a reasonable expectation that most people simple won't bother on their crappy pseudo browsers, because even the act of inputting the url is a fairly large hassle.
I would say that if you're dealing with option B you're pretty safe just delivering an experience that is tailored for a browser like Netscape 1.1 (just dust off whatever you were doing in 1995 and you're good to go! :)
The vast majority of mobile phone users have a phone that was purchased within the last few years, and any users that have a phone older than that are unlikely to want to use the internet from their mobile. Personally I think you would be better of making a high-end 'AJAXified' site with all the bells and whistles and a standard XHTML-MP site that would be accessible to most users.
You should use XHTML-MP for mobile versions of sites. You'll get better continuity with the non-mobile version and it will work with more (particularly newer) devices
I am working in the web dept of a large legal firm, and among other things am responsible for maintaining a professional look for all our email communications (over 600 pieces per year).
Right now I am in a rut. Using a lot of pressure and manipulation, a person in management got to "art direct" a couple of HTML emails working directly with a member of my team and I caught the design at the last moment.
Her "designs" introduced background images behind the text of the emails along with additional, high-contrast imagery sitting behind the title in the header.
I ended up mandating a design change, however she is very insistent on "her" design and questioning all my reasoning for simplifying the look.
Basically she is questioning my expertise and asking for "proof" that her design is not user friendly.
I have the meeting in a couple of hours and was wondering if anyone here could point me to resources that discuss these specific items:
Argument against background images positioned behind the copy of an email. The images are at about 10% opacity, which makes them incomprehensible, and makes the design busy and ugly (my perspective).
Argument against high-contrast images behind titles.
Now, I am aware of the technical implications of including images in HTML emails, Outlook 2007 not loading background images etc. This is not necessary a technical issue, but a serious aesthetic/usability step in the wrong direction.
Thank you!
Facts:
Common sense in communicating dictates that anything that distracts you away from the message -- the content of the emails is not a good idea.
Is there images in the background of your letter heads and on all your invoices? Why so? Why not?
What do background images contribute to the value and perception of the message, the image of your corporation? Is it clearly known the impacts they have?
Go take a look at email newsletter sites. They are covered in guides and tutorials on how to email market effectively.
www.icontact.com
www.constantcontact.com
and so on..
Opinions:
Emails are not meant to be flyers. They are meant to communicate, clearly, simply and concisely while bringing a professional image. Making it look like a cartoon, or a flower shop, or whatever else you are dealing with probably doesn't add to it.
The issue you may run into is she is taking it personally because she is attached to the design for personal reasons and not designing for the needs of the business. So an attack on the design is an attack on her. She is too involved with her ego of looking good and avoiding looking bad or wanting some kind of glory.
Simply put, she should be the one qualifying to you why it IS good design, not the other way around. If she doesn't know, why is she asking you to prove it to her? How would she understand?
There's a book called Dealing with difficult people that may be of use to you.
Of course, if common sense was really common we wouldn't have to point it out as being common sense.
Update us on what happens!
http://www.asciiribbon.org/.
They have a lot of points on why not to use HTML ect, in emails.
Quite a few e-mail clients do not support HTML e-mail.
Other clients have a very poor or broken HTML rendering, causing the messages to be unreadable as well.
Sending HTML e-mails causes great overhead, and is very inefficient.
People that are limited to a text-only terminal, people with disabilities, blind people, basically anyone that cannot use a graphical interface easily or at all, are likely unable to read your mail.
(Extract from link)
In addition to what others have said, consider legal accessibility requirements. I found one example of the US Department of Education accessibility requirements. I'm sure searching for this one can find more examples.
Although it doesn't really apply, you may be able to reference the Americans With Disabilities Act, assuming you're in America.
Also, since you're sending HTTP formatted mail, maybe the Web Content Accessibility Guidelines 1.0 are of interest. For example, Guideline 2.2 of this document states "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen."
A professional email should only be graphic-intensive if those graphics either emulate the look of the company stationary, emulates the look of the company site, or if the graphics are interactive. A common example where this makes reasonable sense would be billing emails from Amazon.com. Note, however, that the content itself does not actually have any graphics, only the frame above, below, and to the sides of the content uses graphics. Similar stuff shows up in banking emails and paypal emails. This sort of thing makes it easier for people to associate the email with the site and makes for nicer printed records that match the online version of the same records.
For standard communication, I'd just go with a header and/or footer graphic.
What I did was escalate to a person who has both the position and understanding of the importance of the issue. Also, presented a version with a cleaner design. Made sure to address all objectives, and did not imply that design decisions are open to discussion.
I HATE email with designs and pictures on it. It is unprofessional IMO
I hate them.
the desirability/niceness of designs and art are subjective. So, how can you be sure all the people who receive them will appreciate them.
For me they are a big turnoff.
Also consider looking up some references in Human Factors engineering texts that show readibility studies. I bet a quick library search in this area would yield much scientific data that her way causing reading errors, eye strain and or slower reading speed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a development process question.
Background: I work for a modest sized website where, historically, the designers created mockups/screenshots of what they wanted pages and components to look like, and the engineering team (myself included) turned them into html/css.
This works relatively well from a code cleanliness perspective, and helps significantly when it comes to writing javascript. It has fails, however, in helping to maintain consistency from one page/component to another. On one page, a header font might be 12px and on another 11px, largely because its a complicated site with lots to keep track of (and we've cycled through 4 designers.) We have only a few truly universal styles, and they only get used when the engineers recognizes the style - not when the designer tells them to.
Our most recent designer is a relatively capable HTML/CSS coder. We thought we might have him create mockups in HTML/CSS and hand us off the code for quick integration. Our hope was that the designer would be better at being consistent in his style and that it might save us some development time up front.
What we've discovered is that our designer is not quite as good as CSS as we had hoped and that his code is often slightly bloated and incompatible with what we need to do. Also, his style of coding is fundamentally different from the rest of the engineering team and isn't jiving terribly well with our established coding practices.
Question: How do you do the hand off from design to engineering? I know I've heard of companies that let their design team do all of the template coding, but I'm curious how that works. Does the design team actually incorporate members of the engineering team in those scenarios?
As we're structured right now, there's not a chance in hell we'd let our designer write the final templates and check them into SVN, even if he was a proficient HTML wiz. There's too much in the templates that requires knowledge of our codebase and of potential performance issues.
How do we get this process working? Is it a pipe dream?
Specifically - personally - since I come from a web-dev, small-shop background I do the CSS work and slicing the PSD (typically) myself. But then I like to think I'm well rounded like that :)
Generally, the best experience I've had of this was a largish company with very defined groups of developers including the design team who produced the gfx, the apps team who did the vast bulk of server-side coding and app architecture, and the UE (user experience) team who sewed the two together, producing XSLT/JSP/HTML markup in general, and the CSS and JS for the client-side.
There was a very structured process of:
userstory ->
"wireframe" (documents) ->
design (PSD) ->
"flat" markup (DHTML only) ->
integrated markup (with web-app)
Where "wireframe" would be close to a spec for UE, produced with UML or maybe visio. I have heard the term applied to step 4 which I think fits better, but this is what it was referred to as there.
Whilst this works well for the question at hand, I found it had other problems built in. It was very hard to work across teams, and because of the timescales the design team rarely involved UE in decision making (which put UE in some awkward positions), the apps team and design could be working at cross-purposes, and there wasn't a lot of scope to learn in these boxed in teams.
My suspicion (and I think ideal scenario) is that the developers on a project would each be capable of working with, say, 80% of the technology involved (be it CSS, SQL, whatever) to spread the decision control and risk, but each domain would have one (more?) "czar" who could act as authority and oversight within the domain. Actually producing those designs is to my mind a strange and magical skill in it's own right so I see no real overlap with developers there, but I think a pool of artists and project teams of cross-skilled programmers would be very powerful.
Apols for the long-windedness. I could go on at considerable length on this, I've spent a lot of time thinking about it.
btw, it seems like you could do with some serious web-devs there, (no offence). Having problems to "maintain consistency from one page/component to another" screams failure to grok CSS
In my experience, unless you limit your design severely, you need real coding skills to build a web page with interaction. Let me elaborate some. If you have built your pages very modular (think of GUI toolkit widgets) you can give your designer a handful of them, he can build the basic structure like playing toy blocks with a nice finishing paint.
Often, modularization alone is not enough for desired interactivity. So, some blocks needs their interactions to be designed carefully as well (like animation, fluid layout to accommodate indeterminate content, customized behaviour via extra javascript, caching to eliminate redundant requests and speeding up things) or ability to accommodate minor presentation variations, which brings us to the realm of programming, where you calculate dimensions, enable/disable parts, keep track of time, preload stuff, invalidate preloaded stuff and so on.
Enter HTML/CSS/JS. They are more of a product of evolution than intelligent design. You cannot always declare your intent and be done with it. You need attributes declared in your html, stupid hacks in CSS combined with extra markup, ridiculous amounts of js to smooth rough edges, duplicate rendering code on the server side. These tool were never meant to build applications.
I don't think one can achieve a complete separation of design and application development in these tools at hand. The effort required is too high to justify the marginal returns.
If you end up heavily modifying designer's code (which is othen the case if he is not one of the developers also), there is no point in making him suffer trying to express his intent using the wrong tools, nor developers breaking the design while modifying it and consequently fixing it. I don't even mention user experience.
In my opinion, no small internet businesses who want to ship a product in a reasonable time should spend their scarce resources to go against the grain. Let people do what they do best in collaboration if necessary. If you can't divide design process at an arbitrary satisfying point, you may as well not bother to separate at all. Pipelining works well for machines whose goal is determined to the last detail and not changing. I can't say the same for humans building and designing things be it software or hardware.
Where I work it's basically the same. Designers create mock-ups and specifications of the UI design, right down to the pixel, and the developer creates HTML/CSS/code out of that.
The reason I say code, is that we use UI frameworks (namely, GWT), and as much as we would want to, code and CSS styles are still very coupled. I do not believe there exists one UI framework in which code can be completely decoupled from the UI design.
So I guess for now it's still entirely the developers job. Though I would like to hear about organization which are able to hand off some of the work to designers.
The problem with handoffs is that the idea and implementation of one group is not going to match the abilities and implementation of the next group. Just by their nature handoffs are going to be wrought with problems. So what is an alternative to the ubiquitous handoff scenario? I think that integrating the user experience (UX) into an agile and iterative development process makes sure that what is really important occurs:
The customer's needs are researched then validated.
Early and continuous collaborating between usability experts, designers and programmers.
The actual process works by having everyone collaborate with the customer up-front on their needs. Then the design is researched and prototyped in the iteration before coding begins. Thus when coding is occurring, the next set of designs are being worked on. Programmers should be looking forward at what designers are doing and the designers look back to be sure programmers are on target. Once a design is coded, it goes to the customer for acceptance, by that time the programmers are working on the next set of interfaces.
Jeff Patton did a podcast on Agile UX recently that goes into some of the implementation concepts and common problems.
There is a whole group on Yahoo dedicated to agile usability (which mostly involves interface design).
For the CSS inconsistencies... I'd just suggest making a style guide then trying to stick to it. Have someone be in charge of "design consistency" that way the can spank anyone inventing yet another way to display the user.
At my company, my ideal work flow doesn't work very often, but sometimes it does. I löve when this happens: The engineers write the webapp and output semantic html with only minimal CSS. then you have the designers do the CSS.
I like it when it goes this way, because:
It is easy for me to write semantic
HTML.
I am not very good at coming up
with a good design for my semantic
html.
It is entirely possible to do
the CSS without asking me questions.
The markup just speaks for itself.
However, this rarely works. Because:
The CSS has to be modified whenever the HTML changes and the designers' time is sparse.
Moreover, our designers don't enjoy styling my markup, and fighting for their time is not pleasant.
Our designers often want to change the markup. Mostly because they believe some layouts cannot be done without changing the markup or because they believe that it's the only way to make IE obey. They are technically not able to change the markup, though.
I have my doubts about many of their cases. Many times they claim IE incompatibility, I strongly doubt they really know IE that well. There are neat CSS hacks to make IE obey without resorting to
<br clear="all">
So, sadly, usually this ideal is a little off for me.
A separate designer - developer workflow is the best way to go. Designing a website and coding it are altogether different jobs. There are issues of cross browser compatability, CSS, XHTML, apart from coding standards to deal with.
You could also opt for outsourcing your HTML to a specialized PSD to HTML conversion expert like us (ButterflyHTML). It may work out cost effective in the long run