What does a front-end web developer do?
Front-end web developers, the “artists” formerly known as web designers
are the bunch of people in the company that make sure that the data coming
from the backend gets displayed on the browser. They also make sure it looks
as closely as possible as the design, that ,
CED
came up with, and that the user can navigate through it, accessing the data.
They don’t need to know about complex OO
programming, tricky database structures or how a path is done in Illustrator.
They get data from the backend people and an example how the result looks like
from CED.
All they need to do is to hack some
HTML or
XSLT
together and link the different documents. Piece of cake.
Web developers don’t have it as easy as it sounds though. True enough,
markup languages are easy to learn and scripting languages are not much harder,
but there is an aspect of uncertainty, that has to be taken into consideration,
when judging their skills.
As a web developer you work in an uncertain environment. What looks good
and works on your computer can be a popup hell and dire to look at on the
machine next to you or on the machine of a customer. The first is not much
of a problem, just ask your colleague to upgrade his browser, the second,
however, is a problem.
As a web developer, your work can be wrecked by users and customers in
many ways:
They can
- use a browser that is completely outdated
- set his browser font to “very small” or “very large”
- use a video card that displays 16 colours only
- run a resolution of 640×480 pixels and still have the large font
setting - run a resolution of 1024×768 but still keep his window as large as
200×200 - use loads of toolbars to make the area of the screen available for
your site pitifully small - turn off any scripting support for safety reasons
- turn off images to load the pages faster
- use a modem with the speed of two tins connected through a wire
- use a
PDA - use a text-only browser
and if the site does not work with that, they’ll blame you for it.
In other words, you never know what is going to be the mean of display
at the other end.
What to do about that? Don’t fret, there are standards that the World
Wide Web Consortium (W3C) defined a long time ago. Just follow these
standards and you are safe.
The only problem is that the browser industry keeps telling their
products follow these standards, but, in reality, they don’t.
So by doing the right thing, you do the wrong thing. By following the
standards, you make sure that your site will perform fine in future browsers
and display units. On nowadays and yesterdays browsers though, there might
be loads of issues.
What you do need to do is to make sure your site is following the
standards and still looks OK on older browsers. This is the perfect
option. Another would be to define a certain browser and platform
environment. This is possible when we are talking about Intranets and
B2B sites, but
B2C means you are in
trouble.
You are really in trouble, when the design you got was done by a designer
who is not firm in web design. The web is a media, not a sheet of paper.
Designs that look really nice on paper (and impress customers) might not
work on the web. Same as screen layouts do not work on television or game
consoles.
Users are able to resize the text part of your page, or, in newer
browsers even add own rules of display onto your site (through own stylesheets).
This means that every layout, that relies on fixed font-sizes, and text,
that can only use up a certain area, is doomed to fail.
You can go the other extreme and keep everything flexible, which may
result in really ugly texts, with lines too long to be readable. This is a
minor issue though, as, when the user has a problem with that, he can
simply resize his browser window.
In any case a good web developer needs to know a lot about the media he
works in.
He needs to know
- what browser/platform configuration breaks your page when you use
which technology - which technology or elements to use to create the navigation in
- what to do to avoid wrong display on browsers
- how to keep the size of the final document small
- how to convert graphics so that they are small in file size and yet
good looking - how to deal with data coming from the customer in various and
sometimes rather exotic formats - how to keep his work from stalling when there is no data coming in
that he can use. - How to communicate to colleagues or customers that the amount of
final data in the product does not really fit the design (which is a case
of bad planning to begin with, but it does happen) - How to keep up with the rapid web development market and techniques.
These are the most obvious bits. Another obstacle a web developer has
to tackle all the time is the media and software market hype.
At every computer fair and in magazines software companies advertise
products, that help you do a web site in 20 minutes without knowing anything
about code. For good measure you can also add all the multimedia you want
and connect it to the database, you don’t know anything about either.
When looking at these ads one starts to wonder why people care about
hacking in their HTML.
Front-end development is considered a task that can be fulfilled by any
application or even the export filter of a graphics development program.
True, these applications do put out
HTML and Javascript.
True, the results look good. Wrong, they can replace a web developer. They
can replace a “web designer”, someone who hand-codes “HTML designs”. When
talking about HTML designs, I mean web sites without any other purpose but
being eye candy. Standalone, plain HTML documents, a few links, some rollovers,
but no back end connections or interactvity. Sites that are nothing but an ad
can be safely done with them. As soon as you need the site to fulfil a specific
task, be really optimised and fit the other components in your development
framework, these WYSIWYG
editors (like Dreamweaver, Frontpage, Adobe Pagemill and so forth)
stop being that handy.
The worst nightmare for a front-end developer is to be confronted with
markup code generated by these programs. A script or application can never
optimise like a human being can, the code is bloated, unreadable and not
logically structured in most of the cases. Keeping in mind that the outcome
was meant to look great for 20 minutes work, why would it? The user never
sees the source code. The developer does, and it’s his job to keep it as
small, fast and readable as possible. Especially when you remember, that he
might have to hand it over to another developer for changes.
The availability of web content is amazing and great, but also has a
downside to it. Content and code can be published immediately and is
available to everybody. This is very nice and actually one of the main
reasons to make people start web developing. After all it’s easier to create
your first web site than to try and get some time on TV or radio. The
downside of it is that content gets published without any quality testing.
Any enthusiastic developer, with more drive than skill. creates some new,
cool design or effect, and publishes it on his web site. As it is cool and
new, other developers see it, and implement it as well, to stand out from the
crowd. Looking at this effect closely makes it obvious that it only makes
sense in a very restricted browser environment and only for some content.
Sometimes it might not even make sense at all. Nevertheless it becomes more
and more spread and used, and sooner or later customers will see it and want
it as well. Or colleagues see it, don’t realise the flaws it might have
(as it works on their browser) and offer it to the customer.
Then the web developer gets asked to implement it, and gets blamed when
it does fail in the quality test.
There is no such thing as free lunch. Also there is no such thing as a
perfect web site that you assemble from free content from the web without
knowing what you do. Script libraries and personal developer sites advertise
their content much like software companies. They claim their products have
perfect output. Truth is, you can find anything on the web, and that is
great, but make sure you test it thoroughly before you even think about
using it in a product someone pays you for.
To conclude, the web developer is the developer on the project that has
it all: A very unstable display environment, a skill set that needs to
range from code to design and usability, and the blame when the end product
does not look the way it should.
It’s a hybrid position, you are someone that paints with code.
Programmers don’t accept your work as real code, and designers don’t
consider it design.
Now you might be at the point where you ask yourself: If that is such a
horrid position in the development circle why bother taking it?
Well, the love for the media I suppose. The challenge to make things
visible to users and not exclude a lot of them. The hybrid position in
between programmers and designers and dealing with both. The satisfaction
of seeing things you have done online and realising that people use it.
The immediate satisfaction of hacking in some funny words with brackets
around them and controlling the layout of a text by doing so.
It is a position that needs constant improvement, and interest in the
media you work for. The days of front-end developers that attend a 2 day
course and make a lot of money the week after are over. Now it is the job
to clean up the mess those “web designers” left behind. To work with
design and backend and project managers to make sure the customer gets
something that is looking good and works fast and reliable.
