Working on web projects means being organised and setting up our computer to make it easy to keep an eye on all details, such as file extensions, media dimensions and extensions. The first steps is to configure the preferences of our workspace and get ready to keep the upcoming files organised in a logical way by setting up fitting folders.
On a Mac, our project work will have its own folder inside the user folder, or within one of the subfolders within. This really depends on our own preferences - importantly, we decide on a set up and stick to it.
folder setup
At the start of the project work, we’ll create one folder for all related files and possibly some sub-folders in preparation of the files to come. This might look like this:
The main folder will be named to reflect the project or to state our client by name, the sub-folders’ names will indicate their content and organise the different files into fitting categories. The most important aspect is to avoid a messy collection of files and to make it easy to find files during the ongoing work. We can make use of the options in the operating system to view our folder structure and the included files.
viewing file extensions and details
Being able to quickly check on the details of our files, especially any media files such as images, we’ll configure the preferences from the start. In Mac OS, this is done via the Finder preferences: click on the desktop to access the Finder > top menu > Preferences > Advanced - check the Show all filename extensions checkbox.
With this preference in place, we can now quickly see the details of any selected file when in column view mode, very handy :)
On a PC, our project will have its own folder inside the main PC folder, or within one of the subfolders within, such as the ’Documents’ folder, for example. This really depends on our own preferences - importantly, we decide on a set up and stick to it.
folder setup
At the start of the project work, we’ll create one folder for all related files and possibly some sub-folders in preparation of the files to come. This might look like this:
The main folder will be named to reflect the project or to state our client by name, the sub-folders’ names will indicate their content and organise the different files into fitting categories. The most important aspect is to avoid a messy collection of files and to make it easy to find files during the ongoing work. We can make use of the options in the operating system to view our folder structure and the included files.
viewing file extensions and details
Being able to quickly check on the details of our files, especially any media files such as images, we’ll configure the preferences from the start. In Windows, this is done via the File Explorer View settings: open the File Explorer > View tab > Show/hide - check the Filename extensions checkbox.
With this setting in place, we can now quickly see the details of any selected file in the details panel, very handy :)
local and remote files
In addition to our working design files - we will have to get used to having 2 sets of identical files for our web projects' files, in two different locations: we will have a local and a remote version of our website - one on our computer and one on the online server. This might feel initially a little odd if you're not used to it. However, it is very logical and quite easy to remember. It will soon become second nature ツ
We will have the same files locally (i.e. on our computer) as well as remotely (i.e. on the server). We can name our files as fitting our projects for all but one page: the file name of the homepage has to be index.html.
index.html = homepage
This file has to be located in the main directory. It is the website's homepage which the browser will look for when accessing the domain/site folder.
taking screenshots
One of the most often used commands is the screenshot. We use it to keep records of details, to capture windows and settings, and to show our setups to our team mates. Troubleshooting anything is easiest done via the sharing of a quick screenshot - be that something to do with settings, or when our webpage's design looks broken.
In OSX, we can take capture various parts of our screen - for each of these options, you will hear a shutter sound to confirm the screenshot was taken. The image will appear in the bottom right corner of your screen and you can click it to edit it or add annotations. Without clicking it, the image will be saved to the desktop after a few seconds. The following key combination diagrams are taken from the official Apple website - please read 'Take a screenshot on your Mac' for further details.
capture the full screen
For a screenshot of the entire screen, including the top menu - press down these three keys at once: Shift + Command + 3.
capture only a select part of the screen
To take a screenshot of only a certain part of your screen - press down these three keys at once: Shift + Command + 4. This time you will see the cursor change to a crosshair icon which will allow you to select the part you want to capture. Click and drag to select the area, then release your mouse to take the screenshot.
capture a window
To take a screenshot of only a certain part of your screen - press down these three keys at once: Shift + Command + 4 + Space bar. This time the cursor will show a camera icon. Click on the open window to capture the image.
In Windows, we will use the snipping tool which shows the options available via the drop-down menu for 'Mode'. Selecting our chosen option, this tool will capture the image and open in a new window. This window will then offer options to annotate, save (via top menu > File > Save) or email the image. The following images are taken from the Micorosft site, please read the 'Use Snipping Tool to capture screenshots' for further details.
For quick access, there are various keybboard short cuts available:
In Firefox, both on Mac or PC, we have the function to take screenshots built-in. This will allow us to either capture only a select part of the screen or take a screenshot of the entire window, including anything that is hidden from view.
To access this function, right-click on the webpage. We can now choose to select a certain part of the page's content by clicking on it, or choose to click and drag to make the selection or select the 'Save full page' option.
Once the screenshot is taken, we can opt to copy the image (to paste it elsewhere) or to download it as PNG. It will be saved to the default download directory set in Firefox preferences.
considering our team
One of the most wonderful aspects of web design is the collaboration and team work. This begins with a solid approach to the file setup in terms of format, size and colour space. It then expands to being a considerate co-worker who will share files prepared with the view of another person having to make sense of our layers and files. The following slide deck is a recap of important aspects to think about when starting a new project.
When we work on web design, the list of tools we might use is seemingly endless and ever growing and changing. Yet the tools is less important that the work we do with it. My advice to you as you're starting out is not to get hung up on your choice of app but to be open-minded and experiment to find which suit you.
As mentioned before, pen and paper will always be the most useful start to our design process. We should remember what excellent immediacy sketching and drawing brings to the process. Great for brain storming, discussion and team work.
The digital tools will be needed to shape and execute our ideas. The days of having to know a certain piece of software to get work are over ~ it is the quality of our work that will get us the job. We'll need to remain flexible and willing to learn new tools all the time. This means we can focus on the design work itself instead ツ
naming project files
As we begin a design project, we will produce quite a number of files, from drafts and ideas, to iterations and revisions to the final design files. This means that fairly soon we’re dealing with many files. Giving each file a meaningful name will save us lots of headaches and time.
We’ll use an example project that includes a logo and site design for a fictional client, Hattie’s Tea Room, and look at the steps involved to organise our work flow and files.
Naming our files will help with the overall workflow, whether we are the only person working on the project or whether we’re team working. This applies to all aspects:
content: text/visuals/media
planning: site plans/wireframes/mockups
design: branding/icons/layouts/style guides
development: prototypes/production
My advice to newbies is to get into the habit of good naming straight away. It is easier to learn a new method than aiming to change your ways later on. And this applies to your own work, and to working in a team. You will go back to an old project at times and it’ll be easier to find a file if your folder and file names still make sense to you. And if you’re team working, your collaborators will be much happier if they don’t have to guess or open up all files to find a specific design.
meaningful naming
One of the easiest ways to improve our workflow is to name our files according to their content. This will mean we can assume or conclude what a file contains without having to open it up. How exactly we choose to approach this will depend on content and focus of the image.
In our example project, we might collect research images such as different kinds of teapots, for example. This file collection could quickly grow and it would be useful to be able to quickly refer back to a specific file. For clear names of our teapot images, we might reference the design/shape of the pot. Alternatively, we could refer to the material or style of decoration ~ there are plenty of possible options.
keeping track of iterations
Once we’re in the flow of the design work (saving files into our ’work-in-progress’ folder we set up earlier), the next question is how to name the different design versions we create. Another complication that arises is how to best label revisions and iterations of the different versions. Deciding on a clear method for this will save endless confusions and duplications. Ideally, the file name will be specific and clearly state a reference.
Including version numbers in the file name for clear labelling will help refer to a specific design and its iteration at the same time. Once the initial versions have been proposed, the version numbers can then be added to (rather than re-named entirely), keeping all iterations linked to their original version. For example, the next iteration of the first version might be called: htr-logo-v01-1-traditional.afdesign.
organising files & folders
While we might start out with a fairly simple approach and only a few folders the the number of files will keep growing. It will be best to do a little tidy-up every so often. This might mean to ’shelf’ the early work on design versions and put related files into another sub-folder, to be kept for reference and archiving. We can then set up new folders for further revisions of the ongoing design work, such as iterations on typesetting or colour schemes.
Importantly, we will stick to meaningful names for any new folders and ensure that their names will clearly reference the content and are tied to the work included. This all becomes even more essential when we work on the website design and the site files as outlined in the following section.
When it comes to the files involved in a website, there are many additional aspects to consider when getting set up and organised. Firstly, there’ll be content to be produced or collected and organised. This will then lead to the planning of the content structure, followed by the wireframing, mock-ups and prototypes. For static sites, the last folder will be for the site files themselves.
the planning folder
Any site project starts with a planning folder, a place to initially collect all content. The content then gets analysed, reviewed and revised with an eye on the site’s goal and target group.
Once the content has been prepared for online presentation, it is used for the site planning. This will involve brainstorming and site map iterations to come up with the best structure, the most effective IA (information architecture) for the site.
the work-in-progress folder
With a site plan in hand, it’s time for design work and prototyping. This folder will keep track of all our working files and could be organised into various different sub-folders. We could first work on mockups and then move onto prototyping, for example. Essentially, this folder will include all ongoing design work.
The nature of files and formats will vary and it will be a good idea to keep links to any online work as reference as well. We could save the web shortcuts, or keep the URLs in a simple text file. It will be important to keep track of all ongoing work, regardless of app or platform.
The website folder itself only includes files used for the site itself. It’s vital to consider both the structure of this folder and the names of all files within. A webpage will refer to each of its elements by file path, name and extension. This is why we initially configured our workspace for quick viewing of both sub-/folder structure and file extension.
naming conventions for web
The naming conventions for web files are not optional, they are an essential aspect of a well-functioning and easily found website. Server setups can vary (throwing up errors if file names are badly formed) and search engines will assess our file names (penalising poorly named pages) ~ sticking strictly to good file names is therefore of the utmost importance.
Meaningful names.
File names should be descriptive both for an easy workflow as well as for the benefit of SEO (search engine optimisation). Avoiding abstract abbreviations or single letter/digit file names will be a more effective approach.
All lowercase.
Different operating systems treat capitalisation in filenames differently. Using only lowercase will work best across all setups.
No spaces!
URLs literally cannot have spaces in them.
Since we’re making websites & everything is an URL, our filenames cannot have spaces. For names including multiple words, we will use hyphens as separators.
Only letters, numbers, and dashes (-).
URLs only allow ASCII characters unless the characters are encoded. Since the specification specifically disallows non-ASCII characters our filenames will use only basic characters.
While underscores for separation of words are permitted and can work, hyphens are preferable as many search engines (such as Google) will interpret them as separators, resulting in better search terms.
You might notice that our examples both for design as well as the site files follow this same convention. While it is not absolutely necessary for the design files themselves (before they are added to the site), it is a good idea to stick to the same method for naming of all files. One less thing to worry about when we move the final design files into our site folders :)
website folder
The structure of our website folder can take one of many different approaches. This will all depend on the complexity of the site in hand and we might organise our files by site section or file type. Generally speaking, we'll keep our structure as simple as possible.
Let's look at our example project and how its files might best be organised. For small projects likes this one, the folder structure can be quite simple and the sub-folders set up to reflect our site structure. Our site plan shows 4 sections with varying numbers of sub-pages. The required files will be of different formats: image files (JPG/PNG) for visual content and HTML/CSS for textual content and design.
As there are only a small number files with specific purpose, it will be logical to group the pages together and setup an image folder for all visual elements. This will keep the structure simple and we can choose to add more files as well as sub-folders easily in future should the site grow in content.
If you are new to webdesign your sites will likely be relatively small and therefore the following illustrated structure will serve you well.
If the site was more complex and included many more files, we might have a sub-folder per section which includes separate sub-subfolders for pages and assets. The most important aspect is to approach the structure of folder logically to make it easy to work with. File paths will be the ’glue’ that will bring it all together, hence keeping it simple and clear will be the most effective method.
website folder inside our project folder
To recap: this is how our website folder fits into our overall project folder. All site files will remain inside this folder during the development work.
The file organisation inside this site folder should be decided upon when coding begins. The file paths will be set and would need to be changed if folder/files are reshuffled or renamed.
manual versioning
When we worked on our design files, we were creating iterations of individual files and giving them numbers to keep track of revisions, edits and updates. This is fairly easy as it is one single file only, one that includes all elements in a single instance initially. When it comes to our website design however, this is not quite as straight forward. The site folder should only include files that are used for the site, and doing versions of individual parts within will soon result in a messy folder with too many unused files.
Once you are progressing in your journey into web design/development, you will explore tools for ’versioning’ - a method of working which keeps track of edits to files and code. Popular platforms are GitHub and Bitbucket and you will likely learn how to use these in due course. At the very beginning however, I would advise you not worry about learning these tools. They are quite complex and you will certainly look into them when you feel ready.
As a beginner however, first things first - it will be best to focus on learning the basics. And there is an easy way to still do some form of versioning which I would recommend: doing manual backups to keep track of your progress.
At any point where we make substantial changes to our site, be that to edit the markup (HTML) for a new content structure, or the design (CSS) for an update to layout - we make a copy of the entire site folder. Adding version numbers to keep track of the progress, we can then keep the existing version as reference and work on a new copy. If we make mistakes in our update, we can easily refer back to the previous iteration and restore a broken bit of code by copying it from the earlier version into the new one. A great safeguard against our own mistakes ~ and a great way to collaborate too.
keep it simple & clear.
While this all might sound complicated ~ good file naming will definitely be a worth-while habit to get into. The pattern or method you start using matters less than the fact that you do consider your file and folder naming from the start. For your own sake as well as that of your team and co-workers.
Keeping file names short, meaningful as well as using only lowercase and no spaces or special characters is a good approach for nearly all digital work. You might realise it straight away ~ but you will soon appreciate it youself ツ
The more we collaborate - the more fun the work will be and the better the result. We should therefore be ready to share our progress early on, collaborate and share work-in-progress files as much as possible. This means being mindful of how our team workers think, which apps they use and how we can best prepare our files for a smooth workflow between people.
A design file might start off quite messy ~ while we’re in the flow of coming up with ideas and concepts, our focus will be on the work itself, less so the neat organisation of our graphics and visual elements. And this is fine as long as we don’t get lost in our own mess :)
artboards/layers
Before we share our files with others however, we should tidy up and show them the courtesy of a neat and easy-to-use file. Organising our graphics into layers, using clear phrasing for names and making our file easy to understand will show that we respect everyone’s time and input.
Meaningful names.
for both file names as well as artboards/layers within. Before we share our working files, we will make sure that our file is easy to understand. This means the file name itself is descriptive and the artboards and layers are organised and named according to their content, too. Short and succinct names will allow everyone to jump straight in and find their way around our files easily.
Grids and guides.
Most design files will include some form of guides to align the graphic elements. We might use the inherent functions offered by the software or do those manually. If different apps are used by our collaborators it can be useful to create our own guides and place them all on a separate layer. This layer can then be hidden easily for a clear view of the design.
Work with artboards if possible.
Depending on the app in use, avoiding placing different versions on different layers will save time and make it easier to compare iterations. This is usually easily possible in vector app and will save time.
working with fonts
If our design includes fonts, we will have to bear in mind that not everyone will have the typeface in use installed on their machine. Sending any file with editable text can result in font substitutions and therefore render our design into something entirely different. It will no longer look as we designed it as a different font will be used instead.
Depending on whether or not everyone needs to be able to edit the typesetting - we have these 2 options:
share the font file
If typesetting is part of the collaboration, we will have to share all fonts in use alongside the design file; fonts will need to be installed to ensure the work in hand will render as designed.
outline all text elements
If typesetting is not part of the collaboration, then all text can be converted to a graphic; the functions are usually called something like ’convert to curves’ or ’outline type’.
Everyone is swamped with communications, emails and attachments - so it should be our aim not to add to this overload. It will be best not to send files individually but to create a folder to collect all required files. This will include the working file, any reference material (unless embedded into our file) as well as font files as needed. The appropriately named folder can then be compressed and sent easily in one neat package.
When it comes to collaborating on website designs and getting help with coding issues (for static sites) - the same as for the artwork files applies. We will send the folder with all required files. In the case of a site design, this might include additional files such as mockups, or links to prototypes, for example.
By this stage, the design files are not likely to be needed as editable versions and so we will send easy-to-view formats, like PDF or JPG/PNG files, instead. Prototypes will likely be online so we'll send the web shortcuts for easy access.
inspect online
One of the quickest ways to get help with our code is to make sure the site is online. We can then not only check on the code ourselves in different browsers and use the built-in tools to trouble-shoot - but anyone else can do the same.
Here is a screenshot of this page's header viewed via the ’inspect’ function. We can use the built-in tool by right-clicking an element and selecting inspect from the drop-down menu. An in-window panel will open where we can view the markup (HTML) and check on the CSS and its layout properties and much more. This will make for very easy collaboration ~ our code can be tested and viewed quickly as it is readily available online.
As mentioned, it is important to make any team efforts as smooth as possible. No matter which kind of files we are sharing, sending a ZIP file with all files and folders will be much quicker to send/download and much easier to work with than asking people to keep track of many different individual files.
We should only ever send the files that are needed for the work in hand, keep our naming easy to understand and avoid overloading our helpers by all means. Should a file be too heavy to email (which can be the case with some design work) - we can use online services such as wetransfer.
back up! back up!! + back up again!
This is probably stating the obvious, I know - but I have to repeat this anyway. Do ensure you're backing up all your work, and more than just once. Making sure you have a copy of your files in more than one place will give you peace of mind should things go wrong. Ideally, you'll keep one copy on your working machine, one on an external drive and an online copy, too. That way you will always be able to get your files back if technical disaster strikes.
There are many ways you can do this - here's what I do: I use CarbonCopyCloner to backup to an external drive and SYNC to back up my files online. Both are set to do this automatically at regular times.
If you like, you can use my referral link to sign up to sync.com - which will give us each an extra 1GB in space ~ nice - but don’t feel obliged ツ
Backups are one of those things - we don’t really think of them until we need them, until there’s a problem. And things can go wrong: a technical glitch, a lost or broken device and all of a sudden, we have to find a way to get our files back, if possible at all. A good backup system will be a life saver ~ so don’t risk having to learn this the hard way - get yourself set up with a solid cycle of backups and you won’t get caught out :)
collaboration
One of the most wonderful aspects of design work, especially for the web, lies in collaboration and feedback cycles. No good design never succeeds in isolation - after all, our project is made for people, has a clear objective and has to deliver on its mission. The goals and aims of our sites might vary - but they are all designed for people. People with different view points, with different habits - using a whole variety of different devices, too. Without feedback and input from those we design for, we'd surely fall short.
Giving and receiving feedback
Feedback cycles can take many different shapes and forms. We might do a formal presentation to our team. The Q&A can then evolve into a discussion to share views and feedback. Or we might merely have some informal chats, by our desks or via online chats. The method of feedback will just flow with the context or the team ~ what matters most is the feedback itself ツ
From brainstorming initial ideas, to evolving concepts and design proposals and iterations, the tools we use should be right for the team. Sometimes this will be pen and paper, post-its or whiteboards. Other times we might opt for digital tools. ‘Moored’ is a free and nice little tool which can be used to brainstorm, collect feedback and more. Great for freelancers to get insights from clients, or larger teams to collaborate ~ try it out ツ
Some wireframing tools, such as Figma, Whimsical or XD, offer the function to collaborate and leave comments on specific elements. All depends on the context, the scale of the project as well as the team. When you're new to design and design conversations, my advice would be to explore available options and find one that suits you for your projects. When you collaborate with others, you could suggest your preferred tool, or find out and learn others.
The changing role of the designer
The four principles
understand people
focus on the people
solving the right problem, not the symptom
always be iterating and improving
versioning.
As our skills and projects grow, the need for keeping track of versions becomes more important too. The manual versions mentioned previously are a useful first step but when it comes to collaboration and team work, this method will soon become too basic and more difficult to manage.
Collaborating on code in teams means we want to keep a record of which edits were done and by whom, be able to go back to a prior version and leave notes on any new changes done. This means we will likely use a versioning tool. This is definitely 'developer land' ツ and might look quite intimidating to start off with ~ but I would recommend that you explore the options as soon as you feel ready.
online code-sharing platforms
codepen online community and development environment for front-end web designers and developers; includes an online code editor which serves as an interactive and open-source learning platform
Bitbucket Git-based source code repository hosting platform which supports various programming languages and offers versioning control
github version control using Git, code repostitory hosting platform for collaboration, code sharing, and widely used by developers as portfolio as well as contribution to the open-source community
