Creating Responsive Web Sites - IEEE Brand Experience
IEEE.org

Creating Responsive Web Sites

  1. Home
  2. /
  3. Assets & Guidelines
  4. /
  5. Digital Guidelines
  6. /
  7. Mobile/App and Responsive Design Guidelines
  8. /
  9. Responsive Web Design Guidelines for IEEE Sites
  10. /
  11. Creating Responsive Web Sites

Responsive Web Design Guidelines for IEEE Sites

Creating Responsive Web Sites

If a new site is being constructed or an existing site is being rebuilt, it should be constructed using responsive web design (RWD) techniques to ensure that it is as cross-platform-capable as possible. This means that if you follow traditional workflows for web design and development, you are potentially tripling your work, making tasks like wire-framing for RWD a nightmare. You are not only defining the structure for the page as it appears on the desktop/laptop screen but, at a minimum, two breakpoints where the interface is changed (smartphone and tablet) as well. Couple that with the need for fluid designs between the breakpoints and the traditional static wireframe/comp/development approach to project management becomes a hindrance where multiple iterations of multiple designs will take up more and more time with diminishing impact on quality. Instead, it is recommended to adopt a "lean UX" approach, where hard-copy deliverables are replaced by iterative and agile prototyping tools.

On this page:

Planning

Planning should be done as quickly as possible with as few details as necessary to move to prototyping.

  • Content: Considering that the content that is going into any site is always the best place to start a web project, this becomes even more imperative for a responsive website, where the content will be re-purposed into multiple displays. Start by creating a content inventory.
  • Functionality: As with content, the functionality may differ greatly between interface breakpoints, so it's important to consider what functionality is required and set priorities. Keep the requirements high level for now, though, since the actual implementation details will likely change when you are prototyping them.
  • Architecture: Plan the general structure of the pages, including what navigation types, content types, and functionality types need to be included on different page types. This may be as simple as a quick wireframe sketch on a white board or paper or a spreadsheet of page requirements, but it does not need to be a high-fidelity "blueprint" of each page.
  • Design: Define the basic design styles using a mood board that includes color palette, typography, and image styles. This is not a detailed pixel-perfect design of each page, just the general design style guidelines that the team can reference.
  • Platforms: What devices or platforms will you be supporting? One difficulty you will encounter is with the number and fragmentation of device types, especially in the Android world. You will want to define the supported devices up front so that you can test continuously and quickly. The numbers of devices are constantly fluctuating, so it is pointless to present it here, but you can check with the Android Developer's website for up-to-date platform versions or StatCounter Global Stats for a broader overview of browser versions being used.

Prototyping

Responsive prototyping allows you to quickly plan and iterate the design of your website without resorting to laborious static wireframes and comps. Instead of drawing static interfaces with programs like Visa, OmniGraffle, or Photoshop, use a prototyping tool.

Building

Your build phase will depend on the platform or content management system you are using for your site. Some content management systems will already have themes that can be implemented, while others may require development from scratch. If you are developing from scratch, it is recommended to start with a "liquid" framework such Skeleton. Both are bare bones and semantic HTML and CSS code that provide simple responsive code to start development around.

Content

Once a site has been implemented, for the most part, the job is done. However, there are some important considerations that site content managers should be aware of.

  • Use properly formed semantic HTML5 to ensure that the styles will work. This can be especially true with images where the new <figure> and <figcaption> tags are in use to ensure that images can be resized or replaced.
  • If RESS is being used for image sizes, make sure to create all required versions of the images.
  • Video will need to be converted to HTML5 formats and embedded using the video tag.

Testing

Test early and test often. Testing should be performed as often as possible throughout the prototyping and build phase. When testing your RWD, it is important to use as broad a spectrum of devices as possible. Carefully define the devices you will be expected to support before beginning your project, making sure to have access to these during the testing phase. For designers and developers wishing to preview their work, there are two recommended applications:

  • The Responsinator (web): For quick testing of designs across a wide range of different device sizes and orientations, The Responsinator provides a simple tool that simulates the most popular iOS and Android devices. Simply type the URL you want to preview into the form field in the top left corner and the URL will be displayed in various orientations and dimensions. It is important to note, though, that these are only size simulations and will not fully simulate the device, so the site may behave differently on the actual device.
  • Google Chrome: For final acceptance testing, Google Chrome allows you to display a live website from a desktop/laptop version of Google Chrome broadcast onto any iOS and Android devices. For ore information, visit https://support.google.com/chrome/answer/9430554