Theming is not only about adding decorations. It’s also about altering structure and modifying user experience.
A good approach is with wireframes, mockups with specs and modular design. This way you only focus on the important parts first. Unfortunately sometimes you start with printed stuff (the design), no specs and no patterns in the design (where e.g. two pages look completely different). Try to prevent this.
Since web sites are not print, you should work with proportions instead of absolute measures. Use the font size as the base. Then make paddings and margins relative to the font size. Finally decide on the size of the other elements.
If you don’t start with a mobile experience, you are doing graceful degradation instead of progressive enhancement. The latter is harder do design, but should improve performance. But apparently mobile browsers download everything even if the CSS will not be applied (because the media query does not match).
Do not focus on decorations. Instead focus on a black and white version and add colours and graphical elements later. Otherwise you are adding lipstick to a pig.
By starting out with he black and white version, it also immediately becomes clear that typography is very important. But it is also complex. It encompasses both single characters and the text as a whole. Besides fonts, space is also essential: line heights, spacing between paragraphs, spacing between words (e.g. caused by justified text). Please give your design space.
A tip regarding web fonts: when you use them, please make sure you do
it right. Do not include a different name for a variant of a font
(e.g. MyFont
and MyFontBold
for example), but give them the same
name and change the font-weight
or font-style
.
A grid is a creative constraint and provides an exoskeleton to the page. It is a tool that helps in placing stuff. Simone warns us to avoid fluid grid. Because they take up a certain proportion of the screen, they will not work on small screens for example. You could for instance use the Deco grid system.
You can also make your own grid. If you use a good starting point (e.g. the Golden Grid System) it is not that hard. For responsive design, you will have a different number of columns based on the screen size.
CSS preprocessors are a handy tool. Simone gave an example using Less. For simple examples, the benefit might not be clear. But if you use variables for colours and need to change a colour, the benefit is obvious: you only need to change it in one place (instead of doing a global search and replace). Whenever you use CSS3 and need vendor prefixes, preprocessors can handle them automatically for you if you want to so you don’t have to be bothered with it.
Simone presents statistics for IE usage and gives us a list of
bugs/missing features for IE 6–9. Tricks: use
modernizr.js
to include browser specific
optimisations and throw away borders for old IE since they cause a lot of
problems due to a broken box model.
In Plone there are too many page types to generate a design for each of them. It’s easier to decompose a page into blocks and widgets which can be reused. Twitter’s bootstrap is more than a set of CSS. It’s a documented set of widgets. But you can also generate something similar yourself.
Try to reuse the classes already available in Plone. For instance, do not create your own class to hide content. There’s markup for tables, tabs, portlets, etc. There’s also JavaScript available you can reuse, such as jQuery.
With Diazo you can for instance wrap existing elements with custom
tags (e.g. a <div>
with a class or id). XSL also provides
if
…then
…else
constructions you might want to use. You can also
override classes if needed (because you didn’t reuse the Plone
classes). Diazo might be overkill. You might also use
z3c.jbot to override
templates.
Theming is a complicated thing. But if you communicate you can get feedback and accomplish teamwork. This will lead to a better result. If you are working on a team, do not settle for anything less than “good.” If something looks bad, the customer will also complain about it so it’s better to do a good job straight away.
]]>An approach that is quite popular these days is to create a separate
mobile site. In most cases visitors of the ‘desktop’ site of
example.com
are redirected to the mobile version on m.example.com
as soon as the site detects (or thinks) that the client is a mobile
device.
And there we already see the first problem with this approach. What exactly is a “mobile device”? We can probably agree on a smartphone. But what about tablets? An iPad, for example, has a resolution of 1024 x 768 pixels. Isn’t that the same resolution a lot of designs are made for?
So is an iPad a mobile device? If your answer is no, what about an iPhone 4? With a resolution of 960 x 640 it gets awfully close. So is every smartphone a mobile device? Perhaps we should focus on the size of the screen. But where to draw the line? 10 inch, 7, smaller?
Perhaps the term “mobile” should not be defined just by the specifications of the device, but by how the device is used. For instance, you would probably use your smartphone while waiting in a queue, but not your laptop. However, using that definition will open another can of worms.
The life of a modern web developer is even more complex. We may want to optimize the content of the mobile site or application for low bandwidth conditions of 3G or EDGE networks. But user agent sniffing doesn’t help here. Smartphones can also be on Wi-Fi. And the other way around, laptops can be tethered and thus have to suck your heavy desktop version through a straw.
In other words, the user agent or even the type of device your are working on, has nothing to do with how much bits per second can be consumed. As a result you should probably try to keep the size of your site to a minimum either way.
There are bad implementations of mobile websites out there. A simple example: you see a link to an interesting article on Twitter. You click on the link and you are directed to the homepage of the mobile site. Good luck finding that interesting article on the mobile version…
Or the other way around: you are reading a nice article on your phone and want to send the link to a friend. Now he’s stuck with the mobile version of the article on his 22 inch monitor.
Another complaint I have is that the mobile sites are often dumbed down. For example a restaurant that only shows the menu and contact information on the mobile site. Perhaps I want to get a feel for the place and like to view the photo gallery. But now I have to switch to the full version. If that option is even available!
Instead of having a separate mobile site, you can use responsive web design. With this approach you use css media queries to change the layout of the page, while serving the same HTML and the same content. In other words: you don’t necessarily care about the type of device your visitor is using, you set the rules on how things should be displayed on certain widths and let the browser handle the rest.
With this approach you do not design separate sites for distinct devices, instead you design for a range of resolutions. So if next month a new device comes on the market, your site will probably be ready for it. (The obvious exception is when the new device does not fall in the ranges you had anticipated, e.g. a television with a really high resolution.)
Other people, like Ethan Marcotte in his responsive web design article, describe the concept a lot better. Mikko Ohtamaa also just started a series of blog posts that promises to be very interesting.
Don’t get me wrong, having a (separate) site specifically for mobile devices certainly does have its benefits and can be a good solution. But in my opinion it should not be the first option when building a website or web application that should be “mobile aware”.
Actually, I do not have a conclusion… Although I think responsive web design provides a good solution, it is not the holy grail. As I said at the start of this article, we live in exciting times. There is a lot we still have to discover!
]]>First of all a designer needs to be creative. After all, they are the person that needs to capture the ideas of the client and visualize them. However, it is also very important for the designer to understand the web. Something that works in print, may completely fail in a browser. One of the reasons is that print media is meant to be seen/read, while websites need to be interacted with. Closely related is anticipating user generated content. This means that a design should also look great with less (or more) text than the lorem ipsum in the design.
I think these skills are not disputed. But what about the ability to code? I agree with Lukas Mathis that there are risks when designers are also involved in implementation. In his essay Designers are not Programmers he more or less says that designing and coding are two separate worlds. To be able to be good at designing, you’ll have to ignore everything you know about coding. Otherwise the design is restricted by technical limitations: you know what you can implement and you’ll design within those boundaries. Even worse: by already thinking ahead about the way it’s going to be coded, the focus will be on the code instead of the user experience.
A related discussion is what the deliverable of a design should be. In most of the projects I’m involved in, the design results in a Photoshop file. This file is then cut to extract the needed graphics and the HTML/CSS is coded. I guess you know the drill.
However, quite often the role of designer is combined with the role of front-end developer, especially in smaller shops. In these cases it can be easier to do the design in HTML directly, as described by Meagan Fisher in Make Your Mockup in Markup. (The Django package django.contrib.webdesign even helps by generating sample text.1) One advantage is that some design changes are easier to make in CSS than in Photoshop. Depending on your skills, the whole design process may even be faster. Meagan also demonstrates that CSS3 gives you the ability to create a lot of effects without having to resort to images, which means you’ll have to spend even less time in the graphics editor.
Another advantage of designing in HTML is that the client can see
how the design works in the browser. You have to be careful though:
since it’s only a design, it’s very likely that the code is not cross
browser compatible yet. If the client uses a wrong browser, the design
may not come across as intended. (To prevent this, you could export
the page as an image e.g. by using the Firefox add-on
Screengrab. no longer available)
You’ll also carefully have to manage client expectations. If the design is done in HTML, the client may incorrectly assume the front-end work is done. They may not appreciate the time that is still required to make the site look good in all targeted browsers. Or the time needed to make the static HTML more dynamic by integrating the application or adding AJAX effects.
Perhaps the most important skill of a good designer is being able to communicate. Not just because the design should communicate the right things, but also because communication with the client and development team is, in my opinion, the key to success.
Update (2021-07-16): As of Django 1.8 this functionality is provided via the lorem template tag. ↩︎