Building a website can be a daunting task. Without preparation even more so. Thinking about the following 6 actionable and practical topics will however make the task much easier to digest. In this Floown Slideshare we will be handling goals, design, technical solutions, styleguides, coding and debugging. 6 topics that are truly worth thinking about before building.
3. goal & intent
every project should start with asking yourself (or your
team) a couple of questions. questions that will help
you get a good understanding of what you are trying to
achieve with the website.
4. goal & intent
every project should start with asking yourself (or your
team) a couple of questions. questions that will help
you get a good understanding of what you are trying to
achieve with the website.
answer those questions the best you can.
5. • what is the purpose of the website?
in other words: why were we building this thing again?
6. • what is the purpose of the website?
in other words: why were we building this thing again?
• what goals do you want to reach with the website?
make them specific: 'inform parents', 'persuade
potential customers', 'offer support to existing ones'…
7. • what is the purpose of the website?
in other words: why were we building this thing again?
• what goals do you want to reach with the website?
make them specific: 'inform parents', 'persuade
potential customers', 'offer support to existing ones'…
• who is the target audience?
who is going to visit our website? what are they into?
what can we expect in terms of established knowledge
(tech-savvy? knowledgable about our business, or not?)
8. in our case:
we wanted to inform people about our product
a floown.com production
9. in our case:
we wanted to inform people about our product
persuade them to sign up for the product
a floown.com production
10. in our case:
we wanted to inform people about our product
persuade them to sign up for the product
offer them support if needed
a floown.com production
11. in our case:
we wanted to inform people about our product
persuade them to sign up for the product
offer them support if needed
and help them understand and learn about our vision
a floown.com production
12. this slideshare is a part of the
Startup Collection
get it in your inbox
15. design-first
when the goal is clear, a design should be made that
will help achieve that goal.
understand what content you are putting on the
website that will help you reach your goals. the design
should always be supportive to your content. not the
other way around.
16. • important: never write a single line of code before
the design is finished
17. • important: never write a single line of code before
the design is finished
• make sure the design accounts for mobile, tablet and
retina screens
18. • important: never write a single line of code before
the design is finished
• make sure the design accounts for mobile, tablet and
retina screens
• be at your most critical at the design in THIS stage
think: functionality, feasibility, aesthetics
19. • important: never write a single line of code before
the design is finished
• make sure the design accounts for mobile, tablet and
retina screens
• be at your most critical at the design in THIS stage
think: functionality, feasibility, aesthetics
• get EVERYONE on board. you don’t want to
implement design changes when most of the code
has already been written.
20. in our case:
some time ago we were in such a hurry to launch a
new website… we started coding without a design.
a floown.com production
21. in our case:
some time ago we were in such a hurry to launch a
new website… we started coding without a design.
coding and designing at the same time is never a good
option. not only will you constantly have to scrap good
code, but your design will always be limited by what
constrains your coding abilities at the time.
a floown.com production
22. in our case:
some time ago we were in such a hurry to launch a
new website… we started coding without a design.
coding and designing at the same time is never a good
option. not only will you constantly have to scrap good
code, but your design will always be limited by what
constrains your coding abilities at the time.
don’t do it.
a floown.com production
25. technical foundation
"not every blog should be a wordpress, but sometimes
you just need a wordpress"
there’s a million options to build a website: concrete5,
ghost, joomla, drupal… from scratch
26. technical foundation
"not every blog should be a wordpress, but sometimes
you just need a wordpress"
there’s a million options to build a website: concrete5,
ghost, joomla, drupal… from scratch
just want a blog? you could just move your entire site
to medium and put coding to the side entirely
27. technical foundation
"not every blog should be a wordpress, but sometimes
you just need a wordpress"
there’s a million options to build a website: concrete5,
ghost, joomla, drupal… from scratch
just want a blog? you could just move your entire site
to medium and put coding to the side entirely
it pays to think long and hard about what you need
now, and tomorrow.
28. • speed
it affects your user experience and seo rankings. consider how much functionality you want to
sacrifice to speed everything up.
29. • speed
it affects your user experience and seo rankings. consider how much functionality you want to
sacrifice to speed everything up.
• functionality
sometimes you just want a dashboard with a million options to customize posts and manage
users.
30. • speed
it affects your user experience and seo rankings. consider how much functionality you want to
sacrifice to speed everything up.
• functionality
sometimes you just want a dashboard with a million options to customize posts and manage
users.
• customization
maybe you’re into building very specific stuff. things that any regular cms just doesn’t offer out
of the box.
31. • speed
it affects your user experience and seo rankings. consider how much functionality you want to
sacrifice to speed everything up.
• functionality
sometimes you just want a dashboard with a million options to customize posts and manage
users.
• customization
maybe you’re into building very specific stuff. things that any regular cms just doesn’t offer out
of the box.
• user-friendliness
not everyone is interested in getting all technical. consider who will manage your website. is
that person going to use a terminal and markdown?
32. • speed
it affects your user experience and seo rankings. consider how much functionality you want to
sacrifice to speed everything up.
• functionality
sometimes you just want a dashboard with a million options to customize posts and manage
users.
• customization
maybe you’re into building very specific stuff. things that any regular cms just doesn’t offer out
of the box.
• user-friendliness
not everyone is interested in getting all technical. consider who will manage your website. is
that person going to use a terminal and markdown?
• support
what if the whole thing breaks down? who you’re gonna call?
33. in our case:
we went from a rather sluggish hacked Concrete5 to a
lightweight Jekyll website. did we suffer a bit in user-
friendliness? yes; it’s now harder for non-technical
people to make updates.
a floown.com production
34. in our case:
we went from a rather sluggish hacked Concrete5 to a
lightweight Jekyll website. did we suffer a bit in user-
friendliness? yes; it’s now harder for non-technical
people to make updates.
but we gained so much in speed and customization
options. and the hosting bill decreased too.
a floown.com production
36. styleguide
no matter what technical option you choose, you’re
going to want to implement your design.
37. styleguide
no matter what technical option you choose, you’re
going to want to implement your design.
say hello to css
38. styleguide
no matter what technical option you choose, you’re
going to want to implement your design.
say hello to css
your stylesheet is your bible. treat it as such. declare
the foundation on which your site will be stylized,
before styling any individual div.
39. • use SASS or any other css compiler
this is very important. being able to partialize css
files, define variables and nest will save you time
and trouble.
40. • use SASS or any other css compiler
this is very important. being able to partialize css
files, define variables and nest will save you time
and trouble.
• first: define each and every color used in the design
41. • use SASS or any other css compiler
this is very important. being able to partialize css
files, define variables and nest will save you time
and trouble.
• first: define each and every color used in the design
• second: define standard spacing, fonts, line-heights,
etc.
42. in our case:
for our current website we have managed to built a
much more consistent and easier to manage website.
a floown.com production
43. in our case:
for our current website we have managed to built a
much more consistent and easier to manage website.
the to good design is consistency
a floown.com production
44. in our case:
for our current website we have managed to built a
much more consistent and easier to manage website.
the to good design is consistency
especially when websites tend to get bigger (and they
usually do) there’s more chance of making small
mistakes if there’s no rock solid basis. And those small
mistakes add up.
a floown.com production
46. code consistently & with intent
based on what choices you made you might need to
edit templates or even build the entire thing yourself.
47. code consistently & with intent
based on what choices you made you might need to
edit templates or even build the entire thing yourself.
no matter what, by now you should be armed with a
clear goal, great design, technical solution and full-
fledged stylesheet.
48. code consistently & with intent
based on what choices you made you might need to
edit templates or even build the entire thing yourself.
no matter what, by now you should be armed with a
clear goal, great design, technical solution and full-
fledged stylesheet.
that should give you confidence.
49. • always start with the standard; meaning that
whatever doesn’t need a variation on existing styles
should be done first.
50. • always start with the standard; meaning that
whatever doesn’t need a variation on existing styles
should be done first.
• don’t make shortcuts (if a new variation pops up and
could potentially be used more than once, add it to
the styleguide)
51. • always start with the standard; meaning that
whatever doesn’t need a variation on existing styles
should be done first.
• don’t make shortcuts (if a new variation pops up and
could potentially be used more than once, add it to
the styleguide)
• code clearly: someone other than you should be able
to read it and work with it.
52. in our case:
our current website is based on Jekyll, a very
lightweight blog generator. it’s highly customizable,
but also forces you to do a lot of coding yourself.
a floown.com production
53. in our case:
our current website is based on Jekyll, a very
lightweight blog generator. it’s highly customizable,
but also forces you to do a lot of coding yourself.
we now work with a set layout for all the pages with
includes based on what we want to show.
a floown.com production
54. in our case:
our current website is based on Jekyll, a very
lightweight blog generator. it’s highly customizable,
but also forces you to do a lot of coding yourself.
we now work with a set layout for all the pages with
includes based on what we want to show.
what that really means is there is a consistent system
where every include is coded with a specific goal.
a floown.com production
56. debugging process
there’s no such thing as a perfect execution. if only
because tech evolves: browsers are upgraded, code
solutions are depreciated and screen resolutions seem
to change on a daily basis.
57. debugging process
there’s no such thing as a perfect execution. if only
because tech evolves: browsers are upgraded, code
solutions are depreciated and screen resolutions seem
to change on a daily basis.
fear not: a solid debugging process will keep
headaches to a minimum
58. • define roles: who will break your website and report issues,
who will solve those issues and who will test the solutions?
59. • define roles: who will break your website and report issues,
who will solve those issues and who will test the solutions?
• define the process: where, when and in what occurrence
will issues be reported? how will priorities be decided and
how often will issues be solved? how much time is in
between implementing a solution and testing it?
60. • define roles: who will break your website and report issues,
who will solve those issues and who will test the solutions?
• define the process: where, when and in what occurrence
will issues be reported? how will priorities be decided and
how often will issues be solved? how much time is in
between implementing a solution and testing it?
• seek a platform: better not leave this process to work on
itself. emails, post-its and meetings do not suffice, find a
platform.
61. in our case:
for our website we use Trello to report issues,
prioritize them and keep track of their status
a floown.com production
62. in our case:
for our website we use Trello to report issues,
prioritize them and keep track of their status
it’s very intuitive and open, which makes it great for
non-technical staff to report and monitor issues
easily.
a floown.com production
63. in our case:
for our website we use Trello to report issues,
prioritize them and keep track of their status
it’s very intuitive and open, which makes it great for
non-technical staff to report and monitor issues
easily.
for more complex and technical projects you might
also need the extra functionality that a service like
github offers.
a floown.com production
65. • goals, goals, goals; know what you’re trying to
achieve
a floown.com production
66. • goals, goals, goals; know what you’re trying to
achieve
• design-first and get everybody on board
a floown.com production
67. • goals, goals, goals; know what you’re trying to
achieve
• design-first and get everybody on board
• technical solutions should be carefully considered
a floown.com production
68. • goals, goals, goals; know what you’re trying to
achieve
• design-first and get everybody on board
• technical solutions should be carefully considered
• the styleguide is always leading
a floown.com production
69. • goals, goals, goals; know what you’re trying to
achieve
• design-first and get everybody on board
• technical solutions should be carefully considered
• the styleguide is always leading
• code with intent & a system
a floown.com production
70. • goals, goals, goals; know what you’re trying to
achieve
• design-first and get everybody on board
• technical solutions should be carefully considered
• the styleguide is always leading
• code with intent & a system
• debug according to a process with set roles
a floown.com production