Building a Website with HTML & CSS

Website Design

Success of the new website (in terms of visits and active use) depends largely on the content offered. The management of your company at the very start came with a description of the scope of the website and an indication of the content to be served.

Website profile

Topic Description Content Functionality Remarks
Scope Selling Data, applications, services, information on content and organization Search on available content, login, online ordering and payment, push news to users (newsletter) Aiming for professional users

Website content overview

Topic Description Functionality Remarks
Data Storage Offer space (different db types), maintenance, backups. As well geospatial as standards
Raw datasets Make searchable (using a map?), various themes and regions. Metadata, give users request on new datasets
Functions Application development Applications for integration in websites Could be made available through cloud services
Services Web services Existing and on demand, link to this company datasets or to customers data Hosted from our company
Cloud services Upload or download Requires account
Web atlas/maps Dynamic atlas and static atlas Easy index of themes and maps

The User

When creating an application, in this case a website, as a developer you want it to be used. Your website will be used if users feel that the content is really appealing for them (it is useful for them or they need it) and if the content is of high quality (it is reliable or credible). If however content is good, but your website is not known or not easy to find, or the website is designed such that it is hard to get to the information you need (it is not usable) then, the website will not generate hits and all effort will be for nothing. Therefore it is undisputably important to design it from the users perspective, the application needs to be designed user- or customer centered. The first step in this process is to identify the users and understand their needs, what they know and on what level they operate.

For this application the user is defined as: a GI Professional. This is a very broad classification and has to be worked-out in more detail. This type of users can be classified by domains or by the use of the various data, functions or services offered to them. For our website, after discussion with the management, has resulted in the following list of users. The table below shows the user profiles extracted from that discussion.

User profile

User
group
Domain/Function Data needs &
level of use
Work environment &
file formats
Application requirements
#1 Municipality Cloud services (data storage), data viewing tools for citizens GeoData and linked municipal information stored in a database a) Login to own space. b) Easy access to cloud services and cloud applications
#2 Water management Data storage, update and viewing tools GIS software a) Login to own space. b) Use on smart phones. c) Easy overview on available applications and services.
#3 Geo Consultancy Sharing tools, discussing plans and data collection CAD software, multiple offices and work at location Overview on available tools, costs, etc.
#4 Atlas publisher Base data and thematic information GIS and Graphics software Reliability of the information
#5 Journalist Link to up to date thematic information and easy to create maps Ready made raster files to include in article Search on theme, region, occurrence, date

The next step in the design process is to get to know the user, starting with listing the user-requirements for each of the groups. The users, as defined above, have to be interviewed to get actual profiles and a better indication of their needs, the usage of the products and the requirements for the website. These tasl will render well defined user requirements and will help in the process of designing an application that follows the user’s expectations and is fully comprehensible (intuitive).

The Requirements

All the requirements outlined in: the user profiles, the website profile and the website content overview, should be addressed in the requirements specifications. The requirements analysis covers the functional and the non-functional aspects of the website. Requirements do not give any information on how to design or to develop the website, or on how to address features, functions and content. Well executed interviews with owners, users and developers should lead to detailed information on the reuiremsnts for the website. Below you will find an example list of requirements that have to be investigated.

 
Functional Requirements describe what the website (the system) should do. To that end the following aspects need to be considered:

  • Platform to be used
  • Use of databases
  • Business Rules
  • Transaction corrections, adjustments and cancellations
  • Administrative functions
  • Authentication
  • Authorization levels
  • Audit Tracking
  • External Interfaces
  • Certification Requirements
  • Reporting Requirements
  • Serving Geo Data system (webgis)
  • Legal or Regulatory Requirements

 
Non-functional Requirements describe the criteria to which the website is expected to conform to, for example:

  • Performance
    • Response Time
    • Throughput
    • Utilization
  • Scalability
  • Capacity
  • Findability
  • Availability
  • Accessibility
  • Reliability
  • Recoverability
  • Maintainability
  • Serviceability
  • Security
  • Regulatory
  • Manageability
  • Data Integrity
  • Interoperability
  • Audit and control

As an example of performance analysis, let's discuss response time. In the majority of places in the world the fastest possible speed that users have access to is 3G. This means that roughly you can transport 96 kilobytes per second, with round trips of about 300 milliseconds. Given this information, we can compute response time using the following formula:

Target loading time (in seconds) × available speed (kilobytes/second) = Target page size (in kilobytes)

This means that if, for example, we want the website to start rendering on the user's screen in 3.5 seconds, the size of the landing page should be:

3.5 s × 96 kb/s = 336 kb

 
Usability Requirements deal with the quality of the interface. The user should not, for example, be puzzled on, where to push or how to proceed. These type of requirements include:

  • Efficiency of use
  • Intuitiveness
  • Learnability
  • Memorability
  • Number of non-catastrophic errors
  • Error handling
  • Help and support

Note that it is beyond the scope of this exercise to work on the complete list of requirements.

Website Architecture

With the information gathered so far, now is the best moment to think about the structure of the website, and spend some time thinking about the architecture. Best is to design a flowchart showing the relations of the various functionality and content areas, which are indicated in the requirements. Some entries are generic and need to be part of the final setup, these are: copyright; disclaimer statements; contact information. Links to Social media and quick links (could be links to business partners) can be an additional entry.

The website has to be served through a webserver. A database will be the container for all hosted datasets and cloud related services.

The core of the website is formed by the five areas as indicated by the management: storage services, raw datasets, thematic atlases, application development and web services. The users call for easy access to the data and services, via a search option by which it should be possible to find the available datasets, maps or services. Search can of course be by typing text, but it can also be a visual search by means of a viewer (can be a map or can be a type of tree-view). Figure 4 shows a skecth of what we considered to be the main elements of the site. Now we need to decide how to lay them out in the site.

 
Fixed, Fluid, Adaptive or Responsive Layout

One of the issues in designing a webpage is dealing with the type of device the website is viewed on. It could be of high importance to have the website in best quality, special designed interface and best performance on every device (desktop, laptop, tablet, smartphone and even smartwatch)? Before starting the design, first decide on which devices the site will be supported. This decision has a large impact on the production of the website in terms of time, coding, content creation and costs. The resolution of the various displays of the different devices is partly cause of the problem, as is the big differences in Operating Systems. Having to develop an application for multiple devices makes the task of the website developing much more challenging.

For example, one of the most popular layout options in the past was to choose for a fixed layout. With this layout type resizing of the browser or diplaying the site on different screen sizes has no influence on how the content of the website is displayed. This works fine for standard screens, but on smaller screens (e.g., tablets or smart phones) the content will not fit to the screen, and therefore horizontal and vertical scrolling bars will appear. This will have a not so positive impact on users' experience in such cases.

Another option is to make the content areas of the website flexible in width and height (fluid). This may solve the problem in a way. The trick of the fluid layout is that the various columns of the website are defined in percentage of space (width) they occupy. This means that they will scale when the browser size shrinks or grows. The content itself does not really scale, it will be re-distributed in the available space of the columns.

It is also possible to create an adaptive layout where you have to create an individual style for each screen size. In this case developers have to check the resolution (size) of the screens that will be used to display the website, and on that basis, decide on the best possible visualization for the website. This is possible by controll elements provided by the Cascading Style Sheet (CSS).

The most optimal solution is of course displaying content on the basis of available space, a menu for instance can be fully shown on a large space, but when only little space is available a pull-down menu or a tree shaped menu may work much better. Decisions on what to display are also done by using media queries. This last option requires most effort: the designer has to make multiple designs for all possible views, the coders have to test on multiple environments and the content providers also have to make sure that it all fits well.

Given the time avilable for our design exercise (this is what we called external requirements, they have nothing to do with the actual product but influence the result), we will go for a fixed layout. Effictively we will focus on the design for one single screen size.

Layout Using a Wireframe

Time has come to start creating the first design with a focus on layout, the technique used is the Wireframe. On purpose all graphics design elements like color, fonts, font-families, images etc., are left out, to avoid distraction from the actual subject and keep focus on the right points: usability and functionality. A wireframe is a sketch of the User Interface (UI) for the (in our case) webpage. This skectch is used for planning the layout, organize the distribution of elements. A wireframe can also serve as a first static prototype to be used in discussion with the management of the company. When placing all the required elements and also all navigation elements on a drawn sketch, the (im)possibilities will show much clearer. Rather than discussing abstract requirements and functionalities, the wireframe helps the users (of the site) to understand the navigation and it helps the company how the selling process is implemented. The use of wireframes helps to define content, indicate what is needed and how much of it will be really used. A wireframe is a great help for the graphics designers to identify where to use color, images and different fonts. For every different page layout a separate wireframe is needed. The figure below shows a wireframe layout of the first page of the website, based on the indicated requirements by the management and the users. Similarly 3 shows the layout of the data viewer page.

Remember, this is just an example. A different designer can (and most likely will), on the basis of the requirements analisys, come up with a complete different proposal on the look and feel of the interface.

Webiste Content

The aim of the new website is to inform the user about the products and services offered by the company. Content is not only a list of elements to be placed on a webpage, but also deals with quality, structure and the story to be told. After discussing the wrieframe and after proper analysis of the companies and users requirements, the list of required content can be produced. The flowchart and the wireframe gives a clear view on structure and the separate pages that this website will have. Content can be described per page. Certain content elements are however used on all pages, these are the generic interface elements (header, navigation, footer), listed and specified in a separate entry.

Content elements

Page Item Description Format in Site Comment
Header Title A Simple Website Plain text
Subtitle Using HTML5 and CSS3 Plain text
Company slogan The source o geo-spatial information, services and APIs Plain text
Main Navigation Buttons Home, Data Viewer, Examples, Contact CSS3 driven
Footer Copyright
Social media Twitter, Youtube, Google+ Link
Company statement Short story about company Plain text
Four links to latest news items Short descriptive title Link Links to separate news pages
Three partners Short message about close partners Text and image of the partner Link to external sites
Home page Datasets Icon serves as button; Dataset title; Short description Button and text Button links to Dataset page
Applications Icon serves as button; Applications title; Short description Button and text Button links to Applications page
Services Icon serves as button; Services title; Short description Button and text Button links to Services page
Atlas Maps serves as button and uses thumbnail map Title, descriptive text and a thumbnail of the atlas map Shows some themes to choose from, links to separate page
Cloud services A title and a short description Text
Download button and short description Button and text Button links to download page
Upload button and short description Button and text Button links to upload page
Data Viewer page Slogan bar 'Visualizations created using OpenLayers, MapServer & D3' Text
Chart area Title, bar chart and description Text and dynamic bar chart Uses local services
Map Area Title, map with zooming and panning options, various layers and a short description Dynamic map, links to bar chart Consuems local and external services

Prototype & Mockup

It is good practice to build a prototype of the User Interface as it communicates the design of the system most effectively and gives potential users insight in the possibilities of the design. In a fully worked-out Design Cycle, this prototype is developed in interactive sessions with the potential users in an iterative manner. The prototype is a series of static pages (can be a more detailed version of the wireframe pages) where some user interaction (click on a button or link) is included. The static pages are placed within a simple website structure, and shows the way the user can navigate.

For an example of such a prototype, check: http://gip.itc.nl/projects/dev/tenure/. For a click-sequence example, check: http://gip.itc.nl/projects/dev/tenure/routemap.html

The mockup is a static digital (raster) image, it resembles the future Graphics User Interface (GUI) of the website. The mockup shows as much as possible the visual appearance in detail: the used color scheme; the font types and sizes; the location and spacing of the elements and; the appearance of buttons (examples of the various stages are included). There are different software tools for the creation of a mockup, often a graphics software is used.

The mockup is a final document, used by all involved developers (coders, GIS, graphics designers, text editors, map makers, etc.) to create the final website. The mockup is a good method to test the final environment before the actual production starts. The website specifications can be derived from this mockup