A Website Design and Development Guide for Digital Humanities Projects
The purpose of this document is to provide a baseline guide to any of the web design and development projects for University of Warwick's Digital Humanities team. This document includes guides for Pre, While, and Post project to-dos, as well as tips, jargons, and links to useful resources. It is hoped that this document will serve as a template to any of the future projects.
In this stage, it is important to understand what the project is, generally. This will provide a clear entry to the project (the history i.e. the story behind the project), what it does (or hoped to do), the impact of the project, and any other relevant questions that can help us better understand the context of the project. In this stage, we should seek to understand:
- The story behind the project
- The aim(s)
- The current development of the database
- add more here
In this stage, it is important to ask the client to lay out everything that they want/need for the project. The table below illustrates the division of tasks between designing and developing the project in the initial stage:
| Design | Explanation |
|---|---|
| Colour preferences | This can be just one or two colours and we can work on them to produce a range of complementary colours. |
| Design preferences | Vocabulary: Flat, Clean, Minimalistic, |
| Design user flow | Create a scenario on how client wants users to interact with the website. |
| Development | Explanation |
|---|---|
| Number of pages | Homepage, About Us, About Project etc. |
| Functionality | Image slider, Featured image, Opt-in button(s). |
| Website Analytics | Google analytics required? |
| Responsive Site | Website needed to be adaptable to any viewport size (from large screens to mobile screens). |
This form will consists of questions that will outline (act as a contract?) the project. Things to outline:
- What your data look like? What to show, and what not? What do you want people to see?
- add more here
In this stage, web designer needs to start wireframing the website, taking what has been discussed earlier into account. Communication with client about progress is essential on this stage. Send out latest design iteration to clients as soon as possible, to elicit response, make changes, and push the latest iteration back to the client. This needs to be done many times until the client is satisfied with the website. In short, these are the process that needs to be done at this stage:
- Wireframing the website
- Mocking up low fidelity version, include colours of choice
- Mocking up high fidelity version, to iterate user experience design esp. font-size, padding between contents, how long/short content will look like, how web components will look (e.g. buttons), etc.
After achieved agreement on the design, it is advisable to sent out an email to the client saying that there should be no more requests to change the layout,colour, functionality. This is to minimise additional tweaks when the site is coded. If the designer is not going to develop the website, the designer needs to prepare a detailed Design Brief, to include all the details from the 3 stages, to pass them to the web developer.
During this stage, there should be no interruption/request from client. The web developer should focus on building the website as per outlined in the Design Brief. The development stage divided into several sub-stages:
- Preparing the local development environment with appropriate software requirement (e.g. Omeka)
- Bootstrapping the design into website (responsive if needed)
- Hooking backend to frontend
- Test layout (CSS)
For this stage, access to live server is needed. Support for this can be requested through IT Services. Once received login credentials, web developer can push all the files onto live server, and tweak anything to make the site fully-functional.
Things to evaluate:
- The whole project as a process
- The website performance (i.e. loading time) It is recommended to keep updated report log in the README.md file for each project, so that DH can trace what works, and what doesn't, to evaluate/re-evaluate the whole development process.
Below are some of the resources that I found useful when working on a project:
- Adobe Kuler - Generating Colour Scheme (https://color.adobe.com)
- UX Project Checklist (http://uxchecklist.github.io/)
- InvisionApp - Mocking up the site (http://www.invisionapp.com/)
- FontAwesome - Icons for the web (http://fontawesome.io/)
- Unheap - A tidy jQuery Repo (http://www.unheap.com/)
- Unsplash - A repo of High Res Photo, suitable for large image background for hero section (https://unsplash.com/)
- CodyHouse - HTML, CSS & Js repo (http://codyhouse.co/)
- Codrops - Free web design resources (http://tympanus.net/codrops/)
- Remodal - Minimalistic modal window (http://vodkabears.github.io/remodal/)
- Pexel - Free stock photo (http://www.pexels.com/)
- Makerbook - A hand-picked directory of free resources
- TweeCool - Custom Twitter integration client (http://www.tweecool.com/)
- Spritecow - CSS generator for spritesheet (http://www.spritecow.com/)
- CALLtoIDEA - Design inspiration (http://www.calltoidea.com/)
- Adam Crymble's Article - Does your historical collection need a database-driven website? (http://www.digitalhumanities.org/dhq/vol/9/1/000206/000206.html)
- Unslider - Image slider (http://unslider.com/)
- Accessibility - design for colour-blind safe, screen-reader, hearing-impaired users
- Above/Below-The-Fold - design decision on whether or not to put informations within the first frame of the browser's width + height. Might want to consider this view (http://buildinternet.com/2008/12/below-the-fold-why-scrolling-isnt-a-bad-thing/) when facing clients with this preference.
- Domain - the URL thingamajig
- Favicon - Icon to represent the website on the tabs of browsers (We need to consider this too in future projects!).
- Responsive Design - Design adaptable to any screen size/width
- ...more to come.