Author Archives: Dano

Signs you Work in UX

As I was reading through this article, I couldn’t believe how much I related to some of these points. Reposted and highlighted with the signs that I have personally experienced 😀

15 Signs you Work in UX

  1. You’re totally comfortable around one-way mirrors
  2. Redesigning a call center application sounds like fun to you
  3. Your spice rack is organized by frequency of use and is within arms-reach of the stovetop (and re-organized on a bi-weekly basis)
  4. You enjoy responding to questions with questions
  5. You wear a point-of-view camera when you go to the supermarket
  6. You take time to explain signage and labeling shortcomings to store clerks and airport attendants
  7. You rage at ambiguously designed traffic signals
  8. You actually read the manuals of things you buy, but only to look for errors and mistakes
  9. You can’t use any interactive device without analyzing its interface
  10. You still cannot explain your job in one sentence to your grandma (I got close.. I described it as “the psychology of User Interfaces and Interaction”, but then she didn’t know what a User Interface was!)
  11. To you, card sorting is not a poker trick
  12. You are immediately tempted to write an expert review whenever confronted with a weird check-out process
  13. Your mom is a persona
  14. A horrible user experience causes you physical pain
  15. You encounter online surveys while browsing the web and automatically start making screenshots

 

CSS border-box FTW!! Now with Sass and Compass!

From Paul Irish’s blog entry…:

One of my least favorite parts about layout with CSS is the relationship of width and padding. … If I say the width is 200px, gosh darn it, it’s gonna be a 200px wide box even if I have 20px of padding. … Anyway, I have a recommendation for your CSS going forward:

*, *:before, *:after { 
    -moz-box-sizing: border-box; 
    -webkit-box-sizing: border-box; 
    box-sizing: border-box; 
}

This gives you the box model you want. Applies it to all elements.

Now you can take this FTW layout moment and make it even more amazing by using Compass (with Sass) and making it a one-liner with no-need-to-type vendor prefixes!

*, *:before, *:after { @include box-sizing(border-box); }

Caveats?

From reading the comments, there appears to be an issue with doing this for images if the image also has a border.  If you use a 100×100 pixel image with a 1px border, the image will actually be scaled down to 98×98 pixels.  This could be a problem with some sites, so i would probably recommend adding another line like:

img { @include box-sizing(content-box); }

Anyway, if I hit any more problems with this, I’ll come back and talk about them.

Waiting for your web services? Hello JSON Mocking!

When we start a development sprint, as a UI / UX team, we will make sure that as a priority, that we identify all of the web services that we will need to consume. We then, define the parameters needed to call the service and generally, we will create a JSON object that we will expect the service to return us.

This helps us shorten the critical path by making sure that the service developers can prioritize their work efficiently, and also move development of web service stubs to the front of their work queue.  This process doesn’t always work perfectly and we are sometimes (often) in a position where the web service developers are days away from even making us a stub, so rather than postponing our own critical path work until later in our sprint, we can pretend we have a working web service using JSON mocking! Hooray!

The Tool : Mockjax

The library I use to fake a working web service is MockJax.  It is wonderfully simple.

  1. The library seamlessly wraps jQuery’s $.ajax command.
  2. You write your ajax call as you would if your service already existed
  3. In your page setup init function, you just once, setup an override based on the URL (and optionally POST type, etc), which can redirect to a function, or a static JSON text file, or another url
  4. When you call your $.ajax, the wrapper checks it’s override dictionary for a match, and if it finds one, it intercepts the call and serves your alternate mock data.

Code Reviews : The Last Line of Defence

When designing the architecture for a web site, not everything you design is about the technology or the code structure.  Perhaps one of the most important project decisions I think I implemented on “Project Shylock” was to implement mandatory code reviews before commit.

All code commits need to pass a build, run and basic sanity check.

The only times committed files won’t require a code review is for a basic copy text change (and maybe even then) or when development was performed as part of Paired Programming (and maybe even then) or for a binary file.

The benefits for code reviews are plastered all over the internet, but just to re-cap from my own personal experience.

Code Reviews produce the least buggy code

I’m sure there are some metrics out there that may prove TDD (Test Driven Development) makes for the least buggy code, but from my own anecdotal experience, nothing makes for more reliable code than having to go through it line-by-line in front of a peer and having to explain your decisions for each line of code.

Additionally, if you promote a development team where noone codes with ego (another topic!), then critical analysis of code structure and logic will flow naturally.  It can be like getting a free refactor just before you commit your changes.

 Code Reviews cross-pollenate knowledge

When I’m working on code in a team that doesn’t code review, the only time I know what everyone else is doing is during the daily scrum standup… and even then I only get a passing overview of their coding day.

When I’m on a team that is doing code review, I always know what 3 or 4 other people have been working on that week.. to the point that if they are away sick and a bug arises related to it, I generally feel comfortable to jump into the code and try my own hand at it.

Last thoughts…

I went away on vacation for 3 weeks and left my team on an honor system to keep code reviewing themselves.  I was unpleasantly surprised to come back that they had been incredibly overloaded and in their work compression mode, they dropped their code reviews.

It’s an easy thing to do to say “Oh I’m too busy to do this”, but in the end, code reviews only take a few minutes most of the time, and can save HOURS of work… sometimes you don’t have to pay that tech debt until weeks later.. but it will be paid sooner or later.. trust me.

UPDATE: Even Jeff Attwood (of Coding Horror/Stack Overflow fame) agrees!

Creating a Website : Style-First Design

Before we started on Project Shylock, we were very badly burned by an extremely high maintenance web form. When we first started designing it, we made a screen mockup that was pixel-perfect and would dynamically resize its windows according to which panes you toggled open and shut. We created a screen first, then made unique design rules that would allow it to be possible.

It looked beautiful!

Only it wasn’t. It was a hot mess of intertwined javascript resize events that would cascade from parent events down to any dynamic child. A form resize or a toggled pane would trigger the display calculation of up to 10 items. By the time we delivered the form, it worked well and responsively, but the cost of sticking to the pixel-perfect screen layout cost us a few weeks of person-hours.

The Lesson : Style First, the rest will follow

When a graphic designer makes a pixel-perfect layout, there is a less-than-complete understanding of how all the pieces are grouped and how they will all push and pull upon each other.

Know your direction

Work out your fonts, your site’s persona, your flavor.  Make some designs on how you want your site layout, look and feel to flow.

Create your styles

Preferably with something like Sass or Less, lock in a gentle css reset, then start building up your styles. Make css modules of related rules. Typography module, color module, padding, layout, buttons, grids, forms, dialogs…  start with the essentials and expand as you need, but make your rules, work out how it all is going to flow

Communicate your rules to designers

If you are working with designers or graphic design team, communicate your styles and rules.  Make a prototype page with examples of how various objects will interact with each other and let them see and play with them.

When they make designs proposals for new functionality, make them use your rules to make the forms.

The pages will follow the design…

If you stay flexible and Keep It Simple (my mantra!), then when you create your pages, they will start naturally fitting in amongst each other and dictating their own flow.  This works especially well in a web site that has to be dynamic or responsive, because as your controls change or your available space, the controls will adapt as well, with minimal developer intervention.

Delete Icon

How to remove a property from a javascript object

Add this to the “I-can’t-believe-I-didn’t-know-this” bucket.

If you have a javascript object that looks like this:

var myObj = { propA : "aaaa", propB : "bbbbb" };

and you need to remove all reference to propA (not just make it null), you could use the following javascript:

delete myObj.propA

which will erase propA entirely from myObj, which would then look like:

{ propB : "bbbbb" }

 

Pass multiple arguments to console.log from another javascript function

One thing we learned from our last project is that console.log can generate a LOT of noise. This noise is OK from a development environment, but once we move into production, it doesn’t make sense to still be writing to the log… that is until something goes horribly wrong in production and we need it enabled again!

For the record, nothing went horribly wrong in production.

So I devised a small helper class that will show or hide console.log messages depending on how you initialize it. The tricky part is that console.log can take multiple parameters, so I had to use console.log.apply(console, arguments); to relay those parameters untouched.

// logging utility library
function Log(_logConsole) {
	var self = this;
	this.logConsole = true;
	this.log = function() {
		if (self.logConsole) {
			console.log.apply(console, arguments);
		}
	};
	this.init = function () {
		if (_logConsole !== undefined) {
			self.logConsole = _logConsole;
		}
	};
	self.init();
}

And invoke it with:

var jsLog = new Log(true); // write to console
jsLog.log('Loading data', data, this);

Best Practice on “Project Shylock”

Our first sprint began with what I’m going to be calling “Project Shylock” that we are making for *******.

I am leading a passionate team of 3 other UI/UX developers who are all trying to make to best possible website that time will allow. The emphasis is particularly on “time will allow“.

Our organization is now known to us to as a place that will not give us realistic time to complete a project. So at some point, time will run out and we will have to make a decision on whether best practice continues, or we deliver all our required functionality.

Time will tell.

Goals

Our team’s goal for this project is:

  • To deliver code that we will be proud of in two years time
  • To use technology that will help, make sense, not just to look good on a resume
  • To be able to handover completed code that will make sense to a future UI developer who may have to maintain it.

Technology and Methodology

  • Sass style sheets
    1. Sass is fucking cool.
    2. .scss format is backwards compatible with regular .css
    3. Allows us to create style module files
    4. Re-usable variables
    5. Can comment with // (seriously, this may be the best thing about Sass!)
  • NOT using Coffeescript
    1. Harder to handover to a fresh developer
    2. Feels backwards to use a language that turns into another language
  • Mocking data with Mockjax
    1. Mocking allows us to develop without having to wait for the backend Java developers (referred to as Backend or BE) to write a service to connect to
    2. Allows us to give an example to BE to demonstrate the desired data contract
    3. We can re-use the mock in a unit test
  • Object Oriented CSS
    1. All styles are defined by classes.
    2. No objects have their own style. They use a styles from a set of rules to display themselves
    3. Close-to-zero page specific css rules
    4. Style rules dictates page layout, not the other way around
  • Unit testing with QUnit
    1. Will initially be avoiding Test Driven Development, as this approach require heavy pre-planning of design, and our delivery structure doesn’t allow for that.
    2. We will be writing unit tests after our functionality is written
    3. Using Mockjax to simulate AJAX transactions
    4. Unit tests will be reviewed in Code Reviews
    5. We will use an automated test runner to execute our unit tests on a frequent schedule
  • Code Reviews
    1. Code reviews are the best way to improve code quality as well as to cross-train team members of other’s functionality
    2. The only two times a code review won’t be required is for a basic copy text change or when development was performed as part of Paired Programming
    3. Code reviews will include copy text and localization (l10n)
    4. Code reviews will include unit tests
  • Paired Programming
    1. There is no requirement for Paired Programming, but if a developer is unsure of the best way to do something or is having difficulty fixing a problem, then why not grab a buddy and work on it together! It’s fun! 🙂
    2. If you pair program something, then you don’t have to do an additional Code Review!
  • Localization (l10n)
    1. Currently the project users don’t need a second language supported, but it will be used in multiple countries and they cannot 100% rule out that it will ALWAYS be in one language (en-US)
    2. Adding l10n once the project is completed is a special punishment reserved for those who spit gum on the street, play techno in apartments at night, or mistreat animals. If there is a chance it will be needed, we will add it to our project from the ground floor.
    3. l10n libraries will be minimalist to invoke, have helper classes and try and avoid getting in the way of development
    4. Copy Text will be organized into property files based on culture, and internally will be grouped into namespaces
  • Javascript
    1. Using jQuery because it makes everything easy and predictable
    2. All code will be enclosed in function encapsulation
    3. Functions will be broken into logical modules
    4. Common modules will be included in each page with a JSP include, so that when we are ready to combine and gzip them, it will be in one place only
    5. Functions will be written with Injection Dependency in mind. Core functionality will take parameters for UI objects and data, so that they are easier to write unit tests for.
  • Responsive
    1. Using FooTable to handle responsive table layout
    2. Using Sass media directives to handle different viewport sizes
    3. Using a percentage-based grid layout to simplify structure and flow
  • Agile Scrum
    1. Everyone says they are doing Agile Scrum, but we really are.
    2. If it’s not in JIRA, being tracked in our current sprint, then it’s not getting done
    3. Do not maintain your own personal “secret list” of things you have to get done. If you keep that list, be willing to work on that list in your own time on the weekend.
    4. Be transparent, put everything substantial into JIRA as a task so we can see what we can fit into a sprint
    5. All tasks in the current sprint to have story points.
    6. Use story point poker cards or shirt sizes to estimate all projects. Have multiple short rounds of estimates and discussions if you cannot agree initially on points
  • Mustache.js HTML Templating
    1. Our last project we chose the simplicity of Underscore.js to do our templating which gives you ERB style embedding and allows you to embed literal javascript code. This unfortunately allows you to write very messy templates with logic embeded right in them
    2. Mustache allows only template defined control blocks which makes templates easier to read
    3. No-code templates promotes MVC architecture
  • MVC (Model-View-Controller) Application Design
    1. The UI layer is broken into 3 sections, Controllers, Models & Views
    2. Models – Our JSON objects that we receive from our AJAX calls
    3. Controllers – Our javascript classes are our controllers, making ajax calls to retrieve our models. Models that are “too raw” for UI consumption are massaged into more consumable shapes
    4. Views – Using Mustache.js templates, we render business-logic-less localized templates

There is almost certainly more stuff we have decided on, and as I remember them I will add them to this list. Additionally, I will try to report back on what decisions worked, and which ones didn’t. I just hope we have enough time to get it done right.

My OSX Bash Shell prompt

I’m rather fond of my bash prompt:

export PS1="\n`tput setaf 6`\w/    `tput setaf 7`(\u@\h)`tput sgr0`\n\$ "

it prints my full path,  then shows me who I am and on which (short) domain.. then on the next line.. a simple indicator as to if i’m root or not .. then the cursor..

Setting this permanently

  1. Change to your home directory cd ~
  2. Make / Edit your .bash_profile file by typing edit .bash_profile
  3. paste the export line into this text file and save it.
  4. All done!

UPDATE: I have now updated to Z-shell, which has fantastic git integration and an entirely new way to configure the prompt!

Admin skull folder

Change your WordPress SuperAdmin User Name for WordPress Multisite

If you are using a Bitnami WordPress (multisite) stack like I am, then your /wp-admin/ login is going to be pre-set to “user”, which:

  • sucks as a name
  • make your login 50% easier to hack
  • can’t be changed in the web UI

If you wanted to login as a custom-named SuperAdmin, you could either

  1. make a new user and make them also a SuperAdmin when setting their role, OR
  2. rename “user” to your desired login

I chose going with route #2 because leaving a SuperAdmin with the login of “user” still leaves a security weakness.

Changing “user” login to “anotheruser” (for example)

admin-user

  1. Connect to your MySQL WordPress Database
  2. In phpMyAdmin, select your wordpress database (mine is named “bitnami_wordpress”)
  3. Navigate to your wp_users table.
    • There will be one row per user.
    • Edit the user_login column for “user” and change it to “anotheruser”
    • Save

Now, this would be ordinarily be enough to just rename your login, but you will lose your SuperAdmin access to your Network Admin if you don’t make one more change.

Making “anotheruser” SuperAdmin to be able to access Network Admin

admin-meta

    1. Count the number of characters in your new login name (eg “anotheruser” has 11 characters)
    2. Navigate to your wp_sitemeta table
    3. Edit the row with a meta-key of “site_admins” and change the meta_value from
      • “a:1:{i:0;s:4:”user“;}” to
      • “a:1:{i:0;s:11:”anotheruser“;}”
      • (the name part is quite obvious, but you also have to manually specify how many characters long the name is)
    4. For me, this change was applied automatically and instantly, but it couldn’t hurt to reboot your server and logout and log in again.