Why do teams make their jobs so hard?

The more developers I meet, the more I realize that developers continue to make their own lives difficult. They simply accept that the environment they work in (technically) is all that they have. They don’t bother learning more advanced things about it, or even trying to customize it in any way. It’s even worse when an entire team chooses to just use the default environment and everybody is left on their own to do what they want to develop the product. Granted there is something to be said about just getting something out the door, but if you just open up your IDE and get coding without ever customizing it to how *you* code you’ll soon be running into headaches.

I may end up making this a series of posts so I can simply hand this out to future team members so they can understand how their life could be vastly improved. The first tool I’ll dig into is StyleCop.

If your team is doing manual code reviews (like every team does, right?) I strongly hope that the reviews don’t cover things about formatting the code or naming conventions. Make use of a tool that can enforce those rules for you automatically. This is especially important for a team of developers where everybody has different preferred programming languages. As an example, my current team consists of developers who have backgrounds in VB6, Clojure, Ruby, and Java. That alone is a plethora of patterns for how the code should be formatted. Because everybody’s background drives how they format their code going forward you can wind up with a lot of source code commits that are purely reformatting of code so the next developer can understand the code. Why waste the resources when you can have a tool tell the developer they aren’t following the rules of the team prior to even checking in?

There’s a lot of rules that some people that don’t agree with, but I’ve found good reasons for nearly every single rule that comes with StyleCop. One of the key things to do when using StyleCop is not to every change the default settings that are installed on the machine. StyleCop allows you to create a settings file for a folder (and all of its children folders) that override its parent. My general approach is that in the root of every project folder I place the Settings.StyleCop folder that should apply to every single project.

Now, in that base settings file, I typically change the following options:

  • Options –> uncheck “Cache StyleCop analysis results”. I’ve yet to hit a project that takes a long time to analyze, so there’s no point in caching results.
  • Settings File –> ensure that “Merge with settings file found in parent folders” is the selected option.
  • Rules –> C# –> Detailed Settings –> check “Analyze generate files”. This way if you’re doing some sort XAML work, any XAML generate fields will be flagged as part of the naming conventions.
  • Rules –> Documentation Rules –> Detailed Settings –> check “Ignore privates”, “Ignore internals” and uncheck “Include fields”. My main reasoning for turning off this level of documentation is that the classes should be very small and concise to adhere to the Single Responsibility Principle. If the class is so massive that you need to document your fields and all the private members, then you really should be having some lengthy conversations in your code review.
  • Rules –> Documentations Rules –> Element Documentation –> Check SA1609, SA1610, SA1628, SA1629, and SA 1630. This way you have everything documented (a) for Intellisense, and (b) so anybody can look at the (hopefully up-to-date) documentation and know what to expect when working with the item.
    • Depending on the team/project, I uncheck SA1600, SA1601, and SA1602. This way StyleCop doesn’t complain about having to document every public or protected element, but when there’s some level of documentation it must meet the criteria.
  • Rules –> Documentation Rules –> File Headers –> Uncheck SA1633, and check SA1639. I don’t believe every file needs to have documentation about the file. The rest of the documentation should describe all of that pretty clearly. But again, if there is any level of documentation in the file header it needs to conform.
  • Rules –> Readability Rules –> Regions –> Check SA1124. For the love of a higher deity, please stop using regions. If you need regions, your code is tackling too much.

That’s quite a bit to configure, but seriously makes your code at least consistent. Not only for yourself, but for your team.

Side Note: For those that use StyleCop, you’ll notice that this means that SA1101: PrefixLocalCallsWithThis. Yes, this is intentional because it does improve readability when I’m looking at the code outside of an IDE. Is the line BuildDetails.Name an instance property digging into the Name property, a static property digging in, and static class, or what? By saying this.BuildDetails.Name it is now much more obvious where I need to look for that code.


Is There A Good Way To Send A Mass Email?

This is going to be more about the options that are out there rather than true technical details.  I’ve done all of these before in the past, but never really put the thought into how the receiver sees these types of emails until lately.

I’m pretty open with handing out my email when a company wants to get it on a form so they “can keep in touch.”  Since GMail is my primary client, it’s capabilities let me deal with the bulk of the incoming junk messages pretty efficiently without a lot of hassle.  Also their spam protection has been pretty top notch from what I (haven’t) seen.  All that being said, the general filtering capabilities of it are the same as any other client: when messages arrive, perform specific tasks on them.  Common filters that people tend to have include “Sent only to me”, “I’m in the TO:”, “I’m in the CC:”, “Sent from somebody/some domain”, “Does it have an attachment”, etc.  When it comes to sending mass emails there’s a few different options and each has an impact on how the receiver’s email client deals with it.

All email addresses in the TO:/CC: field

Most people (and especially companies) shy away from sending a mass email with everybody in the TO: or CC: field these days*.  Why?  What if I’m a rival company to you and I put my email address on your mailing list.  Now you send me an email, along with the rest of your huge list.  I can now look over that entire list of email addresses and add them to my own mailing list and start soliciting to them.  Or taking that list and selling it off to other companies that will spam you.  Granted any company that uses this practice is most likely winding up in a spam folder anyways, but it does mean others now have your email address when you didn’t intend for them to get it.

As a business this is the worst way to mass email your clients.  Yes, the recipient’s email client can process the message based on it’s rules with no problem, but they may have a rule similar to “If I’m not the only recipient, make the message as low priority and move it to this folder I only read during a blue moon on the fifth Tuesday of the month.” 

* Although I’m sure we still have that parent/sibling/grandparent/friend/third-cousin-twice-removed that still sends those absolutely funny photos.  Just as annoying, but not the types of mass emails I’m talking about.

All email addresses in the BCC: field

Well, if we don’t want one recipient to see everybody, let’s just put the entire list in the BCC field since that isn’t sent to the recipients.  Problem solved, right? I suppose from the business’s point of view, it does take care of the concern about people stealing the list of recipients.  But it raises a couple more issues.  First, if you don’t have anybody in the TO: field, a lot of spam filters will deem the email much more likely to be spam.  There’s a number of other criteria that will determine if it is flagged as spam, but not having one email address in the TO: field doesn’t help.  The other issue is that it essentially gives a big middle finger to the recipient if they make use of rules to filter the deluge of emails.  Not having their email address show up in any of the normal fields means that the recipient needs to filter on the other criteria like who sent it.  Why is this an issue? Here’s an example:

Running my own business and domain I am going to receive a ton of email that I actually want to receive (current client emails, newsletters, convention information, partner programs, etc.), but I’ll also receive emails that I should be aware of but didn’t necessarily think about.  Things like emails to the ‘webmaster’ or ‘admin’ of my site are sent to my inbox because of a catch-all email account.  To quickly spot these types of emails it’s nice to be able to have a filter that has rules along the lines of “If <my email address> does not appear in the TO: or CC: field, flag the email for manual investigation”.  Since no email address shows up in the email this filter now catches all those BCC’d emails and flags them even though it’s a regular, legitimate email.

Or another example:  One of the trainers I communicate with at my gym regularly sends out newsletter-like emails, but about 1/5th of the time he also sends out emails directly to me.  The problem is that he tends to use BCC in both cases.  When trying to prioritize my inbox, I would like to quickly skip the newsletters but actually know what’s going on with the other emails.  Since the BCC hides any indication if I was the only recipient or part of a mass mailing trying to create a filter is neigh impossible.  That leaves wasting the time to look at each email.  Granted I know the business value I’m getting by keeping in contact with him so I tolerate it, but for most businesses I look at it as a sign of the business not really putting any thought into how their customers perceive them.

Mail merge each address individually.

This option seems to have the best of both worlds, but it presents a different issue.  When you perform a mail merge, you’re sending out nearly identical emails to lots of people.  There’s a number of spam filters that will start flagging these emails as spam because a large number of extremely similar emails are coming through in such a short amount of time.  Larger companies that send out newsletters and such have realized this and send out batches.  You may have likely noticed this if you subscribe to coupon or deal based newsletters that generally arrive in your inbox at the same time every day, but vary by a few hours.

The other issue with performing mail merges is that normal consumer tools (using Microsoft Word and Outlook) are very limited in the customization of the mail merge.  For example, the subject line cannot be merged.  You also cannot attach files as part of the merge.  To have better dynamic content (say optional paragraphs), they have to be part of the merge data rather than flags controlling whether to add them or not. Once the merge is completed it sends out every email at the same time rather than batching them automatically.

Sure there are some open source projects out there for advanced mail merges, but it takes that extra effort to get that type of functionality.  Most people will only need these tools once or twice, and thus never think about using them regularly.  If the usual tools had some of these features built in the experience would be much better for both the sender and the recipient.

Which option to go with?

So which method should people go with? It really depends on what you’re looking to achieve.  As an end user, I want to see my address in either the TO: or CC: field somewhere.  If I’m BCC’d on an email, I’m likely going to mark it as spam and not even bother reading it. The Mail Merge option would allow for a single individual to appear in one of those fields, but of course it has the limitations I mentioned above.

I know I tend to be an extreme power user for some things, but what other gripes do people have when it comes to handling and filtering email?


That Conference: Git More Done

The final session I attended was presented by Keith Dahlby.

  • Config
    • git help config
    • git config –l
    • You have the system level configs, user configs, and repository level configs
    • git config –e –global (will open up the global config in default text editor)
    • configs are pretty similar to INI files
    • core.editor = <path>
    • diff.renames = false|true|copies
    • difftool.prompt = true|false
    • mergetool.prompt = true|false
    • mergetool.keepBackup = true|false
    • help.autocorrect = 0|N|-1
    • log.date=default|relative|local|iso|rfc short
    • aliasing
  • Named Commits
    • SHA1
      • or the unique initial substring (6 often sufficient)
    • Symbolic references:
      • branch (moves with commits)
      • Tag (remains static)
    • remote references
    • Head = what’s checked out
      • reference to a branch
      • Arbitrary commit (detatched HEAD)
        • on commit, no branch to update
    • ORIG_HEAD = “undo” for big HEAD changes
      • Saved before reset, merge, pull, etc.
    • FETCH_HEAD = last fetched from remote
      • git fetch <url> <branch>
    • MERGE_HEAD = incoming merge heads
    • Relatively naming commits
      • suffixes
        • ~ = parent; ~n = nth-generation grandparent
        • ^=first parent; ^n = nth merge parent
        • 3 commits ago = HEAD~3 = HEAD^^^
        • @{n} = nth prior value for that ref
        • Undo last commit = git reset HEAD@{1}
      • git help revisions
  • Local workflow
    • Ridiculously cheap – use liberally
      • Write SHA to file in refs/heads
    • Branches to clean up
      • git branch – merged
    • Keep Master clean!
    • New topic branch from master
      • git checkout master –b topic
    • Commit more than feels natural
    • git stash
      • Stash away work in progress
      • Typical workflow
        • git stash save “comment…”
        • switch to fix and then switch back
        • git stash pop
      • git stash save –include-untracked
      • git stash list
      • git stash show –p stash@{1}
      • git stash drop stash@{1}
      • git stash branch
    • Temporary Commits
      • Advantage: WIP lives in branch
      • commit, then git reset HEAD~ to go back
    • Reset path in index to match commit:
      • git reset commit  -- <paths>…
    • Unstage:
      • git reset HEAD – stateged-file.txt
    • Reset HEAD reference to commit:
      • git reset [—<mode>] commit
    • Discard previous commit:
      • git reset HEAD~
    • soft reset = move HEAD; don’t reset index/work tree. Essentially an uncommit
    • mixed mode = reset index but not work tree (default). Unstage
    • hard mode = reset index and work tree (discard changes (ignores untracked files); VERY DESTRUCTIVE!!!
    • git add –patch allows for overlapping changes that should be in different commits
      • reformatting
      • refactoring
      • changing functionality
      • Allow for “hunks” (sections of diff) to stage
      • Key operations: y/n, a (all)/d (delete), s (split), e (edit)
      • Also can be done on reset, checkout, and stash save
    • Rewriting History
      • Permanent when pushed
        • Until then, pretend you were perfect
      • git commit –amend (easiest way to change the last commit)
      • alias.cia = commit –amend –C HEAD
        • git cia –a –reset-author
      • git cherry-pick
        • apply changeset(s) elsewhere
          • like to the wrong branch
      • merge vs rebase
        • think of it like shuffling a deck of cards (merging) vs cutting a deck (rebasing)
        • rebasing are a replay of commits
        • rebase –interactive allows for replay with modifications
        • rebase –autosquash … use “fixup! <message>” and git will automatically combine a commit with one awhile ago
        • config rebase.autosquash
  • Fixing “oops”
    • git reflog
      • ls –r .git/logs
        • HEAD, heads, remotes
      • git reflog –all
  • Finding bugs
    • git bisect
      • binary search through a commit space
      • git bisect visualize = view = overview in gitk/log
      • git bisect skip (current version can’t be tested)
      • run my_script = automated bisect
  • http://github.com/dahlbyk/Presentations
  • http://github.com/dahlbyk/posh-git

That Conference: Design for Software: A UX Playbook for Developers

This session was done by Erik Klimczak. I got into it late, and it was standing room only, so I had to jot notes down on my phone. Hopefully these still make sense and there’s not too many typos/autocorrects.

  • James Webb Young quote about ideas
  • Sketch out ideas
  • Sketch early& often to identify edge cases quickly
  • Define patterns, be consistent, reduce steps
  • Storyboarding as a form sketching
  • Drawing app in context of environment will help define usage
  • Tools: sharpie, moleskine, non-photo pencil, neutral gray pen
  • Wireframing to identify interactions, pattern layout, and get stake holder buy in early
  • Good wireframe: content, interaction, layout, hierarchy, functionality
  • Prototyping: whole point is to be wrong
  • Paper prototyping give sense of relative size. Think about things like touch screens and apps.
  • Prototyping is about taking it. Be clever, not complicated
  • Colors: start with solids and add gradients if necessary
  • Be aware of the psychology of colors
  • Use tints of color to add more colors to your palette of 2-3 colors
  • Shades of gray for the chrome of the app
  • Typography: if done right, you don't see it.
  • For print use serif body font with san-serif headers. Generally opposite for digital
  • Pick a typography and stick with it.
  • Rhythm & Scale calculator in Chrome app store
  • Pick a single family with lots of variations to give variety.
  • Visual Communication: telling the most with the least amount on a screen at a time.
  • Basically logically organizing UI.
  • If things look the same or are grouped together, the user expects them to behave the same.
  • Consistent margins, spacing, type size...
  • Reducing colors, and redundancy will greatly help.
  • Grids actually help break up a UI to help with consistent layout
  • Motion: easing should be between 250-350 milliseconds to always feel snappy
  • Animations don't always have to be complete for a user's mind to fill in the blanks.
  • Use motion for long running operations
  • Artefact Animator for C#/XAML
  • Interaction design: user flow is when the interface gets out of the way so the user feels productive
  • Avoid modal states & pop ups
  • Use color cues (red X)
  • Don't block UI
  • Read About Face 3
  • Solicit feedback: if the user doesn't know they can do something or doesn't feel confident about an action, they won't perform the action
  • Mouse adorners, touch/click states, audio, inline feedback (invalid input, password strength), wizards, refresh animations for long operations all are great forms of feedback
  • UX patterns: don't reinvent the wheel
  • Most every pattern you'd need is out there
  • He has a forth-coming book: Design For Software

That Conference: Erlang Goes to Camp!

This session was presented by Bryan Hunter. I figured it’d be interesting to learn more about functional programming in general and how it can interact with .NET more.

  • It’s a functional language
  • Grew out of Prolog
  • Erlang is great at pattern matching
  • OTP (Open Telecom Platform) has libraries, practices and styles)
  • ERTS (Erlang Run-Time System) is more like an OS rather than a VM running on an OS
  • Erlang is open, proven and cross-platform. It simplifies writing reliable, concurrent, distributed systems. Its pattern matching is FTW.
  • On Github
  • Compiled on any platform will run on any other platform
  • Erlang community is more in the Mac & Linux world, but runs great on Windows
  • Erlang supports concurrency very well; especially compared to other languages
  • Concurrency is hard because of sharing state.
  • .NET 4.0 thread allocates 1MB…Erlang Process (Thread) allocates 1KB
  • Distribution was built-in from the start because every process is isolated and everything is done via message passing
  • One Erlang process can essentially watch another process, even on another machine
  • It’s possible to have a true cluster in that there is no master process/node
  • Editing erlang
    • The shell
    • Text editor + command line + shell
  • Every erlang statement is terminated by a period
  • Every variable is upper case
  • Every “atom” is lower case (like function or key word)
  • Lists are defined with []; like L=[100, 200, 5000].
  • Tuples are {}, like Person = {100, “Joe”}.
  • When a node pings another node, it essentially gossips the known nodes to the new one. As soon as nodes know about each other (and the cookies match), there’s full trust to do anything.


That Conference: Testing Code From The Pit Of Despair

This session was presented by Phil Japikse.

  • http://www.telerik.com/zerotoagile for a podcast
  • Legacy Code == any code not under test, has a high technical debt, is icky
  • If the code is working and nobody asks you to change it, why change it?
  • Why change code
    • Killing bugs
    • Adding Features
    • Optimize Resources
    • Removing FUD
  • Make one change at a time
    • Fix or add just one thing
    • Test after every change
    • Commit after every passing test
  • Tools of the trade
    • TDD
      • Building up of the Lego blocks of code
      • Inside-out building
    • BDD
      • Don’t start with individual pieces to build the whole
      • Outside-in building
    • Mocking
      • Fakes, Stubs, and Mocks
      • Fakes have working implementations. They’re Hardcoded, not suitable for production
      • Stubs provide canned answers
      • Mocks are pre-programmed with expectations. Essentially creating a specification. They also record behavior
    • Dependency Inversion
    • UI Testing
      • Typically Manual
      • Often tested by customers
      • Tools becoming better
  • Testing and Refactoring
    • Be save; if you don’t touch the code it won’t break
    • Safety Blanket: Integration tests
    • Code Isolation and Refactoring
      • find a change point
        • Finding the point that breaks
      • create a seam
        • the weakest link of the system/class/method
        • use Dependency Injection
        • use commercial mocking
      • add a new test
        • Use test-eventually style
      • refactor
        • Extract Methods
        • Reduce Complexity
        • DRY
        • SOLID
      • Make sure you’re actually isolated
        • Continue to drill down
        • If code is self documenting, we don’t need as many code comments
      • Fix the target issue
        • Code is isolated, tests are in place, switch to T/BDD
        • It’s turtles all the way down
  • Test/Behavior Driven Development
    • Write a failing test
    • Make the test pass
    • Refactor: Remove magic code; add use cases

That Conference: Managing the .NET Compiler

This session was presented by Jason Bock

  • Talking about Project Roslyn
  • The compiler (csc or vbc) is simply a black box
  • There are 44 switches you can throw at csc!
  • Microsoft wants to stop all the re-implementations of the parsers, thus what Roslyn is meant to be
  • CTP == Could Trash PC
  • Only support for C# & VB initially
  • Can be used for things similar to StyleCop like enforcing consistency.
  • Can be used for a deep understanding of Code
    • Like a WCF Operation Contract that is one way, but is returning a value
    • Can provide quick fixes based on the analysis
  • No time schedule for release

That Conference: Truth and Myth in Software Development

This session was present by Leon Gershing (aka Ruby Buddha). The subtitle is “Truth, Myth and Reality.”

  • Git Immersion and Ruby Koans
  • “Do as I say or…”
    • You’re inferior
    • Your priorities are off
    • You can’t be successful
    • You are worthless
    • You’re not a developer
  • A different way of looking at the world is actually a good thing, stop being negative about it
  • Don’t be so dogmatic about something, it just takes practice.
  • Testing, like everything else, is a tool to help you get better at what you do
  • It’s okay to listen to dogma, but don’t just accept it at face value. Always evaluate the information.
  • Everyone must find their own path; their own subjective reality
  • Myth: that which preceded you is invalid.
    • Reality: waterfall is dead. Long live Agile!
    • Agile is Dead…in the same way that punk is dead
  • Agile manifesto was written by 10 hippies…
  • Perception is Reality
  • Where are you heading?
    • Only you can decide where you want to go
    • No one can tell you the answer except yourself
    • Changing your mind about your current path doesn’t bind you to that path, it changes the direction of the path
  • Find forced mentors
    • people that inspire you on any level
    • Have lots of them
    • remember that celebrity is just being popular, not that you want to be just like him
    • Seek out wisdom from all places; from people and locations of all ages and locations
  • Wisdom, like mustaches and mullets, can’t be given. They must be earned.
  • read the poem “The Perfect High” by Shel Silverstein
  • Pro-tips:
    • Read more code than you write, not books or anything else, just read code
    • Write code, and then write it again, then delete it, then write it again, then delete it, then write it again, then…
    • Play with others. There is a big difference between knowledge and wisdom.
    • Trust your instincts.
    • Think AND Feel. It lets you understand everything and have some empathy
    • Enjoy now.
    • Don’t rely on your own excuses (I don’t have the time).

That Conference: Vim–An Introduction for Visual Studio Developers

Presented by Michael Eaton. I attended this session mainly because I’ve realized how much I rely on the mouse lately and how much it slows me down. I enjoy working on my Lenovo ThinkPad because it has the little mouse stub in the keyboard so my hands never have to travel far from the keyboard, but it still takes time to navigate using the cursor just to navigate around. Not only is that slow, but it’s been killing the index finger to fly across a screen.

  • Everything comes down to “My <insert topic here> is better than yours!”. It really just comes down to “Use what you want to use”
  • Vim is definitely far better for touch typist rather than the hunt-and-peck typists.
  • Vim is designed to be really close to the home row.
  • Vim written by Bram Moolenaar and others.
  • vim/gvim/vsVim/viEmu
  • Command mode, insert mode, visual mode, execute mode
  • [i] to go into Insert Mode
  • [Esc] to go back into Command Mode
  • in CM, [Shift]+[A] to go into the end of a line and goes into insert mode
  • Basically look for a Vim tutorial
  • vim is a pure command line editor
  • gvim is the graphical vim editor so it’s slightly friendlier GUI version of vim
  • http://github.com/alanstevens/KickassVim
  • http://vim.org
  • http://pragprog.com/book/dnvim/practical-vim


That Conference: Designers? We Don’t Need No Stinkin’ Designers!

This session was presented by Jon von Gillern. Admits much of the presentation is based on Mark Miller’s good UX presentation.

  • Wrote Nitriq and Atomiq
  • Why focus on UI?
    • Happy customers == more money
    • Good UI is taken for granted, bad UI is easier to notice
    • Pour UI adds up
  • How can we measure UI
    • Keystrokes
    • Mouse Travel distance
    • Gaze Shift (eye travel distance)
    • Recall Rules of interaction
    • Find signal among noise (don’t make the user think about what they’re looking for)
    • Variance from user mental model (does the UI behave how they expect it to?)
    • Mental Time = Total Time – Physical Time
  • Mental Costs – things that prevent users from getting into the “flow” of being productive
    • Lose of focus
  • Good UI is:
    • Clear (in purpose)
    • Concise
    • Consistent
  • Tools for UI
    • Contrast
      • visual difference between two elements
      • “Visual Weight should match information relevance” – Mark Miller
      • Eyes are attracted to greatest contrast (similar to why young kid’s shows are generally primary colors because they are so different)
      • Nitriq example: Actions have more contract, Information has less contrast
      • Google “WCAG 2.0”
        • Relative Luminance
        • Contrast Ratio
      • Black Text vs White Text article
        • Green, Red, Blue for the order that the eye can tell differences in shades.
      • Testing Tools
    • Color
      • Can represent differences
      • Lots of color == Lots of noise
      • Work with a limited color palatte
      • Hue, Saturation, Luminesces vs Hue, Saturation, Value
      • Pick a hue for a color, and add others by changing the saturation & value
      • Kuler
      • Read the article on Wikipedia
      • ~5% of humans have some form of color deficiency
      • Use Red & Blue, not Red & Green to account for color blindness
    • Size
      • Easier to find large items
      • Important information should be larger
      • Relationship to precision
        • Common actions should be larger
      • Test on the worst device to allow for finding if sizes still work.
    • Ordering
      • You can scan up & down faster than left-to-right
    • Motion
      • Effective for helping guide gaze
      • great for entrance & exits
      • use acceleration/deceleration (easing)
      • Fade in with size at the same time to affect flow documents
    • Shape
      • Icons are a kind of shape
      • Depend on context (flow chart, etc)
    • Fonts
      • Sans-serif: quick to read/recognize
      • Serif
        • better for long chunks of text
        • Character by character legibility (“1” vs “l” vs “I”)
      • Dyslexia
        • Kerning, Symmetry
        • Comic Sans actually helps with this…or just buy a specialized font
    • Parallel vs Serial
      • Don’t display information in serial if it can be done in parallel
        • Modal Dialogs
        • Combo Boxes when seeing all options
    • Shadow/Glow
      • Can help differentiate UI that “sits on top” of other UI
      • Glow can help defuse similar colors that sit on top of other items
    • Gradient
      • Transferring gaze
    • Proximity
      • Similar data should be close
      • Similar actions should be close
      • Vice Versa
      • Bad proximity causes gaze shifting
    • Interaction Patterns
      • http://quince.infragistics.com
      • Remember Parallel vs Serial
      • Just because a pattern doesn’t mean it’s good
      • Immediate, continuous feedback
        • Progress Indicators
        • Preview Hinting
    • Know your users (who, how many, how often)
      • Discoverability
      • How often specific features used
      • gather telemetry
      • Don’t be afraid to steal ideas
    • UI Checklist:
      • What are the 3 most important screens
      • What are the 3 most important pieces of data
      • What are the most important actions
      • Are you using the same terms as your users

That Conference: Roughing It: .NET development from the command line

This session is presented by Jon Polfer.

  • In the beginning was the Command Line
  • Programming is about using words, why not use them as the primary way to interact with the computer
  • Vi/Vim for Unix; VsVim for Vi bindings in Visual Studio; Vi-Emu plays nicer with ReSharper
  • Graphical Vi-Vim Cheat Sheet
  • Using MSBuild
  • CScope
    • Have to create a cscope.files file to tell CScope what files/paths to look into
    • CScope –b –q for building the index only and quietly
  • http://db.tt/PQ2HWqjk for all the code, examples, & slides

That Conference: How to Rapid Prototype Like A Boss

The next several postings are likely to be brain dumps from sessions I attend at That Conference, so they may not make a ton of sense to those who didn’t attend. But then again, why didn’t you go? It’s being held at a water park in Wisconsin Dells in the summer so you can bring your family along with.

This session was presented by Matthew Carver.

  • Author of forthcoming book “The Responsive Web”
  • Wireframes
    • Can be truly rough hand drawings or digital layouts that are still cheap to produce
    • Until a line of code is written, everything is just theory
    • Wireframes can become a “Comp”: Comprehensive Layout
  • Comps
    • Comps are simply a snapshot of the UI, but they lack the full interactions and responsiveness
    • They’re too rigid
  • Why Prototype
    • Fill in the gaps
    • Can anticipate actual scope of the project
    • Offer site/content managers to start testing out ideas before any actual code is written
  • Tools
    • Foundation 3 by Zurb
      • Uses SASS
    • Bootstrap by Twitter
      • Uses LESS
      • Not built specifically for prototyping
    • HAML
      • Specifically for Rails, but makes for quick view development
    • SASS
      • A CSS3 extension
  • Basics of Prototyping
    • Reach conclusions from the wireframing
    • Placeholder images: placehold.it/300x300 == a 300 x 300 image
    • Foundation had a number of build in button style, which gets more into the art direction instead of just prototyping
    • Visibility classes for different browsers/sizes