16th Annual Web Conference April 29 & 30, 2015

My company invited me to attend the Web Conference again. It was great and I really enjoyed going. As usual I’m writing about the event. Hopefully someone else can find this useful as I did. It covers topics relating to mostly web development, but also some about design. I think some of the points can be applicable to other people as well.

Atomic Design

Opening Keynote by Brad Frost

As atoms are the building block for life, so HTML is the building block for websites. Atoms form molecules, which form organisms. So HTML forms components, which form pages, which form systems, which form frameworks, which form websites. For instance, an input field + label + submit button can form a search box, which is a part of a form, which is part of a web page, which is part of a website. It’s important to design a system rather than an individual page. This way there would be less “snowflakes”. Apparently “snowflakes” is a term used even by people outside of my company.

There are tools that can be used to help us design systems. For instance, Pattern Lab is a design system builder that can be used to show and organize colors, fonts, animations, headings, paragraph text, logos, banners, form elements and such that are used on a website. You’ll have to download it to use it on your own server.

Demo

Mustache is another tool that can be used, for templating and keeping content separate from structure. Mustache is useful for iterating through content that uses a repeating structure. It is easy to maintain and update the templates.

Stylify Me is an online tool that lets you see a glimpse of different styles used on a single webpage. Simply type the url of the page in the input field, and hit enter to see an auto-generated style guide. It’s only a rough style guide though and not as powerful as Pattern Lab.

The design process can be slow. The analogy used was as a sculptor chips away at a block of stone to reveal the sculpture underneath, so the design and build process iterates over and over until reaching the final product. Often there is a disconnect between design and development. But we should remember that development is design.

3D Tetris: A Case Study in Phased CMS Migration

Breakout Session by Juliana Perry and Andrea Kaldrovics

This presentation recounts a real life scenario of large content migration from one system to another. The daunting question was “How do you migrate 5,000 pages all at once?” from Adobe C to Drupal. They were faced with two options: have a separate legacy site, and do a gradual migration of the most important content first while keeping the legacy site, until more and more of the site has been migrated.

They faced several challenges such as redesign and a CMS. They had to learn about Drupal and its steep learning curve. Working with design, communication, and web together was a challenge. There were instances of hardcoded content and styles that were done across the board. Those needed to be removed.

CSS is like gardening, cleaning and organizing the code as you work with it, as it grows. If not tended, there will be weeds.

During the course of the project, it was helpful to have a launch checklist to know what needs to be done and the time frame they have. Holding informational sessions for people entering content was helpful for the content providers. They also had a website feedback form at the bottom of every page that helped as people gave feedback on how to improve their user experience. Even after launch, they continued to work to migrate more and more content.

HTML5 + CSS3 + JavaScript -> Visual Interactive Accessible Learning Object

Breakout session by Doug Mills

This was an interesting presentation. The speaker works for the university. He showed us a project he was working on involving the Chemistry Lon Capa quizzes. As the presentation began, it felt like we were in chemistry class, as he educated us on this molecule. The demo involved a complex molecule and click-able regions on a diagram of the molecule. Students were to click on all the locations where there are carbon atoms and submit their answer. If the guess was correct, the app will congratualte them with a message in green. If they guessed incorrectly, they will see a message in red telling them that their guess was incorrect.

Doug showed us his code through the steps that he took to create the quiz app. First he created an app that works as any webpage may work. Then he tackled accessibility through keyboard interaction. Later he introduced issues with people who have poor vision and use high contrast screens. I learned through that, that background images are seen as black boxes in this case, so it’s often better to use images rather than background images. He even designed with blind people in mind, and tried creating for those who use screen readers. It was interesting learning about accessibility through the course of a project such as this one.

Tips:

Think about the user experience in terms of navigation, reading, selecting, and submitting content.

To make a site keyboard friendly, tab indexes and styling :focus are helpful. When designing for high contrast screens, use image tags rather than background images. When designing for screen readers, use roles such as role=”banner”, role=”aria-checked” or role=”navigation” elements.

Resources:

Exploring with Hadi

Campus Expertise CITES

WebAIM Screen Reader Survey

itaccess

The Truth About Your Web App’s Performance

Breakout session by John Riviello

I intentionally picked this topic because I was not familiar with it, but felt that it would be beneficial to know more about, because page speed and performance are very important. Going into it I was hoping to learn about ways to improve performance and speed. Unfortunately it did not address that. It did provide an idea of how to look at page speed and performance data as well as what data you should care about. This presentation was more conceptual than by example so I will just present bullet points.

How fast or slow is your app?

There are multiple tools you can use to test the speed and efficiency of your site.

• webpagetest.org
• Phantomas
• Rum
• Pingdom
• New Relic
• Ruxit
• Appdynamics
• Akamai

Also, what question do you care about?

• Real user monitoring
• W3C navigation timing
• Front-end
  • User authentication
  • Type of user
  • Number of items returned
  • Flash SWF dependency

Gathering the Data

• Work time stamp

  • High resolution time

    Using window.performance.now();

• User Timing vs Surf-N-Perf
  • Serf-N-Perf write less code to use
  • Look at 99% percentile

Summary

• Performance is a feature
• Measure first
• W3C performance API
• Log network
• Log major app-specific events

The Code Cure: Small Steps to a More Organized Front-End Codebase

Breakout session by Matt Wondra

This speech was well organized and very structured. It was clear and helpful for sure. I feel our company and others can benefit from these tips. I jotted some points under each main point that they mentioned.

Take Inventory

We can only solve problems that we care about.

Drop comments

Write about the biggest challenges, conflicts, confusion, anxiety

Evaluate Tools

Tools help enforce our habits (ie Grunt, Codekit, Webpack, Gulp etc)

Install linters to keep coding conventions consistent across all code

Document your steps

Naming Convention

Well-formed conventions make naming easier (BEM)

Establish Javascript naming conventions, and CSS naming conventions

Use consistent file structure

Emphasize Clarity

Coding is for humans, not just computers

If you need to look at HTML to figure out what name represents, it’s unclear

Get rid of clever code hard to understand

Modularize

It’s easier to write, read, edit if the code is in chunks that do different jobs

Stylistic Conventions

Code is more readable when it all looks like it was written by one person

Update your linter

Use HTML style conventions

Documentation

Use helpful comments (answer why the code is there rather than what the code does)

Standardize the format of the documentation

Organize the readme file

Publish

Write a blog post on the work you’ve done

Start sharing your post

Designing a Better Process One Pixel at a Time

Closing Keynote by Emily Rawitsch

This was a fun closing speech about the relationship between people working together, especially UX, designers, and web developers. We can definitely relate to this at our company. I like that Emily told stories to illustrate her points. Her format is less about bullet points.

Emily told the story of how UX and design worked together, and how at a hypothetical company, when the design changes the UX, the UX has to redo their wireframe. Then because the people felt it was inefficient, they just sent black and white design mockups to backend developers for the “wireframe” version, and color version to frontend developers. That was really silly. So they ended up changing their company’s workflow so that the UX doesn’t need to redo their wireframes. The workflow was a lot more efficient and work got done faster. The moral of the story is to not just do stuff because that’s how it’s always been done, but question if it’s the best way to do it.

Her speech mentioned an example of a hypothetical designer and a developer at a hypothetical company working on the same project, and the disconnect between them due to their company’s workflow. She had us raise our hands to see which companies actually had designers and developers working in the same floor in the same area. She also asked which of us have designers and developers on separate floors, separate buildings etc. It was evident that not all of us have the ideal work environment for the best communication workflow between people working on the same project.

Emily mentioned that it would be ideal to have all the people who work on the project to meet together from stage one, instead of having some people meet and then pass the work to developers only to find out what they ask for is not always feasible. Also, it should be an iterative process, not a one time fix. It was interesting that she mentioned the development process should be more about happiness than about clean code. She also mentioned that projects should have readme files so team members and whoever picks up the project later will be more informed.

Some points she mentioned are as follows:

She mentioned about negative and positive affect. For instance visual details have a direct impact on users. People make judgements about a company through their website, and judgements about a website can happen in a fraction of a second (~50 milliseconds). It’s the halo effect. Visuals are really important in this respect. Also, visuals improve usability. Some that looks well organized and well presented appear easier to use than something that looks inconsistent and disorganized, or even less visually pleasing.

Design is a long term investment. It’s about how something works, moreso than just how it looks. It’s not just subjective, but there’s an objective component as well. Designers do their best to present information in a way that easily communicates the message. It’s intensional, not just a personal preference.

The design process is important:

1. Practice Empathy
2. Make it easy, envision it
3. Be objective: use data and AB testing
4. Let it go, done is better than perfect
5. Add delight (have fun)
6. Iterate the process and remember less is more