Modern Web Design Lesson 01 (3 of 4)


Welcome back. So now that you know what front
end is and a little bit more about what a front
end developer does, let’s talk about how
and where this role fits into the grand
scheme of a project. The people in our neighborhood
when it comes to web design are content strategists,
information architects, UX designers, visual designers,
front end developers– hopefully you in not too much
time– back end developers, and project managers. Let’s look a little bit at
what each of these roles does. A content strategist looks
at the content of a site– the words, the
images, the videos– and acts as an overall
editor for the project. She might peruse the content
to ensure stylistic consistency front page to page,
or she might evaluate the content needs of the site. The content strategist puts
together authoring guidelines for future content, and
also establishes a schedule for when content might
need to be updated. In many ways, the
content strategist is looking at the
big picture in terms of what is the message the
site is trying to get across, and how do we do that
most effectively. The next role I
want to talk about is the information architect. The information architect
typically works closely with a content strategist. They may even be the same
person in some instances. And they work to build the
blueprint for the site. Often, they’ll
create documentation like site maps or wire
frames, and they take a look at all of the different moving
parts and kind of architect how those different
pieces fit together and how they work together. The user experience
designer is focused on how the user interacts with a site. This role can overlap a bit
with the information architect and the visual designer,
so it may be rolled into one or both sides of that. And depending on the
skills this person has, they could be generating
drawings, wire frames, graphics, or even
full-blown prototypes. Regardless, the point
of a UX designer’s work is to make complex tasks
easier and more intuitive for your users. The project’s visual
designer is tasked with taking the blueprints and
the other sorts of artifacts that are created for the
site and to then create a distinct visual
design for that project. The visual designer
establishes visual hierarchy, enforces consistency, and
works to guide users naturally through each page,
drawing attention where it’s needed using tools
like proportion, contrast, and white space. A visual designer might produce
a series of page designs, or better yet, a design system
like you’re seeing right here, comprised of headings,
paragraph text, and other sorts of content in order to make
the front end developer’s job easier. Now, the front end
developer– that’s you– are where the rubber
meets the road in terms of producing a website. Your task is to translate the
visual and interaction designs into production-level code,
which means HTML, CSS, and JavaScript. Don’t worry if all of
that doesn’t make sense to you quite yet. By the end of this course,
it absolutely will. Now, working beside you
is the back end developer. The back end developer
may be the person in charge of the
servers, or they might be the person who
integrates your HTML into some sort of
content management system or other server-side
programming language. They’ll probably be the
person building things like shopping carts, login
systems, forums, and the like. And finally, the glue that
holds the whole project together is the project manager. This is the person who is tasked
with organizing the project in terms of schedule,
team, budget, and all that sort of stuff. And they have the thankless
job of managing things like deadlines
and project scope. A good project manager will
keep a project on track and ensure everyone
walks away feeling good about the results, as
well as the process. We’re going to start digging
into HTML in the next lesson. But before we get there, I
want to talk a little bit about two ways in which
teams work together. The first methodology
I want to touch on is the waterfall methodology. And in the waterfall
methodology, one person finishes
their part of the project and then hands it over to the
next person in the process, and then that person
finishes their work and hands it to the next
person, and on and so forth. Hence, waterfall. Most large organizations use
this process, because they’ve used it for years. It’s very similar to the factory
model of an assembly line. Now, an alternate approach
to working together as a team is what’s called
agile methodology. Basically, what agile
means is that you’re iterating and working together. So rather than one
person doing their task, finishing it, handing it to the
next person, and running away, the different people on the
team actually work together and iterate on a given page or
a given interface or a given problem in order to
try and figure out the best solution for it. And that iteration happens
over and over and over again. Along with this
methodology, you’ll often hear terms like
“fail fast and fail often,” because it’s through failing
that we learn from our mistakes and then adapt. And that’s it for this chapter. In the next chapter,
I’m going to dive into a couple of different
philosophical approaches to front end development. I hope to see you
in a few minutes. Now, before I wrap
up this chapter, I want to talk a little
bit about something called templates. I mentioned earlier that back
end developers will sometimes take your front end code and
integrate it into the back end. They do this using what
are called templates. And the reason that
they do this is simple. Let’s say you’ve got four
pages– home, about, contact, and product. On each of those pages, you
might have multiple items that are the same, visualized
here by the orange, purple, and green bars. Now, if something changed in
the orange box, let’s say, it would be really
annoying to have to go into each of
these four pages to change it in each of those
places to match one another. And so, during the
templating process, the back end developer
would actually extract this information into
individual files, sometimes referred to as partials,
that they could then maintain separately from the pages. And the pages
themselves would simply reference those partials. Now, getting a little
bit more complicated, the back end developer will
often take your markup– and don’t worry about
understanding what’s on the screen here, but
they’ll take content like this, which is a module
describing a featured event, and they might add
some logic to it. So if for instance the event has
a photo, it injects the photo. But otherwise, it
doesn’t inject it. Now, I just wanted
to show this to you because I wanted you to be
aware of what templating is and how it can be
really powerful. But don’t worry about it. We’re going to be
sticking to static HTML. Many sites, including
the one that you’re going to be building,
are entirely static. So it’s completely
fine to build only in HTML, CSS, and JavaScript.

Add a Comment

Your email address will not be published. Required fields are marked *