UI Design: No Tools – Wetware

Ryan Singer gave a talk @ a WindyCityRails event about 30 days back around how developers should approach UI design (given he is a leading designer at 37signals in Chicago).

One of the Many Faces of Ryan

· Why it caught my eye 37Signals has some very well designed applications – Basecamp, recent release of Haystack, etc. Ryan is heavily involved in that. · Would I recommend you watch it?: Hrm. Maybe. If you are developer its probably good advice but his more edged points didn’t get much air time … like “punt on AB testing in apps” or “prototyping tools are a waste of time for him – paper and your brain”. I would be intrigued to see him speak at length on those points. · Most Notable Point: UI Design isn’t about slamming prototypes together. It’s about modeling the model in a manner that EVERYONE (business/tech) can understand and then discussion of the language that should be tied to it. He was not talking about the system model. Talking about the problem domain. Very valid point. · Nuance You Might Overlook: His examples from Visual Displays of Quantitative Information and the concept of Less Effective Difference were pretty deep.

So basically, his talk was one were there were comments throughout that made you go … ah. And want to dig in deeper. Hope it helps. Raw notes below.

*** START OF RAW SCRIBBLE TAKEN WHILE RUNNING ***

…….○ 0:37.789 – Intro

…………..§ 37Signals Guy

…….○ 2:30.401 – UI is a software layer

…………..§ Key – customer only sees it … so start from UI view

…………..§ TDD similar to designing to a UI goal

…………..§ 4:54.317 – Example of UI driven code that doesn’t work – the model needs to be right

…………..§ 6:13.593 – Too little language (no verbs, sentences) is bad

…….○ 7:4.261 – Model focus

…………..§ From sentences from business users

…………..§ To data model …. Has one … has many … etc … still understandable by all roles

…………..§ Revised UI uses language, tied to model,

…………..§ 10:3.665 – Partial discussion (UI)

…………..§ Book recommendation – Domain driven design. Talk about how you understand domain goes into code.

…………………□ Model-driven design

…………………□ Ubiquotious language

…….○ 11:35.170 – Screens

…………..§ Define screen scope (pages), screen content, screen layout

…………..§ Don’t start w/ look

…………..§ Examples of how model .. Ties to page scopes … ie Booking/new = register

…………..§ Design inside/out

…………………□ Example of basecamp … focus on messaging first … core of screen … not layout

…………..§ Don’t design in terms of attributes

…………………□ Example – checking if balance is paid before registration

…………………□ Could do person/show … check in button …

…………………□ 16:21.916 – Example of paid and not paid on person/show

…………………□ Design is not art … it is rational … Edward Puffy (sp?)

…………..§ Design screen so important data on screen is

…………………□ Visual display of Quantitative Information (edward Tufte)

……………………….® Least effective difference

……………………………..◊ 19:22.632 example … removing grid .. How it makes data in grid jump

……………………………..◊ Contrast to text … Normal/Bold/Weak

……………………………………► Weak – useful but only in specific context

……………………………..◊ 20:44.91 example – late

……………………………………► Eye scans from attraction to attraction on page

……………………………………► Change text on side bar to 50% grey … can let it go more

……………………………………► Making good contrast means less … so don’t make good ‘green’

……………………………..◊ 23:20.348 – Using little differences … allows scale

……………………………..◊ Example – Actions (4)

……………………………………► 4 things possible on a screen … just links makes all actions the same

……………………………………► Make actions jump by usage

……………………………………► The ‘halo of attention’ see one core you will pick up the light items around it

…….○ 26:15.606 – Flows

…………..§ Stellar UI key

…………..§ Think of things in a series of actions

…………..§ Actions go in threes – get to, do, end point

…….○ 28:9.714 – Templates

…………..§ No HTML in helpers

…………………□ Developers need to realize that HTML in helpers is bad

…………………□ Example of developer trying to change form into code … broke pattern … over abstraction

…………..§ No clever builders

…………..§ CSS and JS us same REST conventions … good … breaking down css files

…………..§ Treat ERB .. As a block … as a helper

…….○ 31:59.240 – Summary

…………..§ UI is about modelling

…………..§ Explict and use a lot of language

…………..§ Break screens out in REST conventions

…………..§ @rjs twitter

…….○ 33:0.935 – Q&A

…………..§ Rails does a lot helpers bad? … form helpers generate one tag (problem is multiple)

…………..§ 34:48.710 – Use of fonts, thoughts? Verdana is great for small fonts. 10pix or smaller. Verdana specializes. Style focused

…………..§ 35:53.790 – mumble mumble? Scanning happens in straight vertical lines. Eye looks for first piece. That is why right aligned text is very bad. Provide single scan line.

…………..§ 35:53.790 – mumble mumble? No clue (bauer comment)

…………..§ 38:3.513 – Removing grid lines, how to flesh out that earlier in design? Depends what you are comfortable in / make changes in quickly.

…………..§ 39:39.276 Design process for him? UI is not photoshop. General idea most work happens in modeling and language. Then go to HTML.

…………..§ 40:47.853 – Do you AB testing? On Marketing side yes. But in app its too much work. One version deploy, watch, adjust if necessary. Ideally get it right w/ a lot of modeling (non-UI)

…………..§ 41:43.540 – Do you new tools like Balsamic/SketchPro? Don’t understand them and purpose. It want something you can’t put down there is paper. If you want to click there is HTML. Speculate that people to like in a complex manner. Waste of time for him. Paper is very flexible … just not sexy. Get excited about end goal.

Testing Rails Applications

Watched Noel Rappin talk at WindyCityRails 2009 regarding testing last month.

· Why it caught my eye I am curious on Test Driven Development and in Rails specifically. · Would I recommend you watch it?: Perhaps. If you are a Rails developer. He focuses primarily on the ways to test different aspects of a Rails system. However, it was hard to track as he was moving so quickly from example to example and at times the code samples were not in the screen. · Most Notable Point: No one thing. Just a nice overview providing samples of how to test the aspects in a ruby stack. · When should you fast forward? If you are in … you are in on this one. There was no high/low.

Hope it helps. A lot of it went beyond my pay grade in the testing arena but its nice to know the macro areas he covers in case I need to zoom to those specific parts.

As always, for those amused here are my raw notes …

*** START OF RAW SCRIBBLE TAKEN WHILE RUNNING ***

……..○ Noel Rappin http://twitter.com/noelrap

…………….VP of Ruby Practice for Pathfinder Development and the author of Professional Ruby on Rails

……..○ WindyCityRails 2009

……..○ http://vimeo.com/6703197

……..

……..○ 0:5.353 – Intro

…………….§ How to test things that are not easy to test

…………….§ Changes should be driven by failed tests

……………………□ Not view, not refactoring

…………….§ Test close to code – controllers w/ controllers, etc

…………….§ Test features – not code

…………….§ Don’t test rails framework

……..○ 3:32.823 – Framework for testing

…………….§ Rspec vs. shoulda

……………………□ Very similar now

…………….§ New to testing – Use default (fixtures, test unit)

……..○ 3:32.823 – Model testing

…………….§ How to test associations

……………………□ Nva –

……………………□ Drive testing from actual feature

…………….§ Don’t do associations as blocks

……..○ 3:32.823 – Named Scopes

…………….§ Find functionality that is composable .. Basically methods

……………………□ Don’t test name scope is passing sql expected

…………….§ Test that it finds objects correctly (does / doesn’t find)

…………….§ Assert_same_elements

……………………□ Works but brittle (if universe of users changes)

……………………□ Better should_have_named_scope macro … positive and negative testing

…………………………..® Code example of the macro (need slides … originally in rspec)

……..○ Rails validations

…………….§ 12:13.682 – always test reg expr

……..○ 13:31.835 – Filters

…………….§ Manage access control – test from functional view

……..○ 15:9.997 – Testing Views

…………….§ Test. Test in such a way that the UI designer changing things doesn’t breaks test.

…………….§ Test for semantic structure level (DOM ID, CSS classes (marker classes to show data row))

…………….§ Assert_select works well

…………….§ Validate view on paper 1st

…………….§ Test for negative conditions is KEY. i.e. Admins have delete button … normal users don’t.

……..○ 18:32.335 – Test for Negative

…………….§ Assert_select … look for DOM ID of X

……………………□ Specify count … 1 or more … or zero … test for zero

……………………□ Psuedo classes … search list element that dom id <> X

……………………□ Specify arbitrary html attribute … validate things are in the form (source of image file, href of <A> etc … don’t tie to UI)

……………………□ ? Syntax … rails finders / sql statement … place holder for list

……………………□ Assert_select can be done in block

…………………………..® Ie sort behavior … use this structure to get view in order and validate order

……..○ 23:19.190 – Helpers

…………….§ Put complex logic from view here (good/bad)

…………….§ Auto generated in 2.3

…………….§ Block helpers

……………………□ Prior to 2.2 hard to test now easy

…………………………..® Assert not logged in

…………….§ 26:18.924 – Testing to output stream … concat

……………………□ Concat is not last call in helper sometimes … get output_buffer (all text to erb_out)

…………….§ Search_select

……………………□ Looks for instance variable response

……..○ 28:25.261 – Email

…………….§ Another kind of view … test structure (sent, values)

…………….§ Assert_select_email … testing sent, not sent … email spec for cucumber allows simulate open of email by target, click on link, etc

……..○ 30:4.191 – Social Networking

…………….§ Testing UserA / UserB changing on events from one another

…………….§ Hard to test (controller tests assume 1 session)

…………….§ Rails integration test – Open session method … works well

……..○ 31:37.880 – Ajax

…………….§ Hard to test

…………….§ Assert_select_rjs … does some stuff good … for rails stuff

…………….§ Blue ridge / screw.unit … just started using … javascript test like Rspec

……………………□ Packages so integrated w/ Rake

……………………□ Screw.unit … tests browser on launch

……..○ 33:46.729 – External Sites

…………….§ Use mock objects to encapsulate sites called

…………….§ Test failure response

……..○ 34:38.160 – Rake Tasks

…………….§ Encapsulate in ruby code (class/method) and test the method

…………….§ Invoke rake task programmatically

……..○ 35:25.222 – Dates and Time

…………….§ Time literals don’t work

…………….§ RESTful auth – intermittent timing error

…………….§ Gem called Timecop … freeze and manipulate time …

……………………□ Put in startup … and teardown

……………………□ Allows you to keep time equal for all test

……………………□ Messes up rake test times … small issue

……..○ 37:8.957 – File Uploads

…………….§ Fixture_file_upload method

……..○ 37:32.106 – Rack / Rails Metal

…………….§ Not a lot of experience here

…………….§ Rails Metal – bypasses rails router for speed

…………….§ Use rack::test … to test

……..○ 38:12.508 – Legacy App

…………….§ No tests (definition of legacy)

…………….§ Black box tests ..

…………….§ use mock objects

……………………□ Isolation

…………….§ Seam – change app that doesn’t current code

……..○ 39:50.347 – Wrap up

…………….§ Look for the tools (a lot exist) in rails environment

……..○ 41:7.876 – Q&A

…………….§ Functional (customer view) versus backend

……………………□ Example of error testing w/ model testing is key

……………………□ Model tests are more key … ditch cucumber if pinched for time

…………….§ Testing when render partial

……………………□ Mock test to verify partial (limited logic in view partial)