KCDC Notes: Second Day

There might have been 1100+ registered and attending on yesterday (Friday May 16), but there were far fewer in attendance today.  There were also fewer bodies among the exhibitors/sponsors/recruiters.  Still a bunch of great sessions.

First Session: Designing touch-first application UX

  • Speaker has been with MSFT for 10 years, used to be an engineer, now does UX
  • Three UX principles: Size, Posture, Interactivity
  • Size: the size of the UI element is inversely related to the error rate of successfully selecting the element. At 5mm the error rate is 1 in 10; at 7mm it’s 1 in 25; at 9mm it’s 1 in 100; at 11mm it’s 1 in 1000.
  • Posture: for a phone, you have to design with the assumption that someone is going to be using it with one hand.  The bigger the screen, the harder it is to reach the top of the screen… which is where back buttons tend to be.  Screenshot for easy, okay, hard for phones. Tablets are two-hand devices and people tend to hold it on the bottom in landscape fashion.
  • Small UI elements are not forbidden, but separation becomes more critical the smaller the UI items are.  The MSDN suggestion is 2mm separation.  The point is that for UI elements that are harder to select accurately you need to minimize hitting the wrong element, so put some separation so that a missed click hits dead pixels instead of another reactive UI element.
  • Regardless of phone or tablet form factor, if you have to change grip on the device to reach a UI element than your design needs improvement.
  • Interactivity: there is a BIG DIFFERENCE between “works for touch” and “designed for touch.” Example: clicking a checkbox on a list of items and then hitting a button to perform an action is the mouse-driven way of doing it; swiping a list item to the left or right to indicate archiving, deleting, etc is a more touch-natural way of doing it.
  • Pull to refresh is another example of touch-specific gestures (as opposed to clicking on a refresh button/element)
  • Q: Is the interaction fast and fluid?
  • Q: Is there feedback immediately after putting your finger down?
  • Q: Is there feedback during the entire time of the interaction?
  • Q: Is it possible to back out of the interaction?
  • If the function of a UI element isn’t obvious then your users won’t like it.
  • JS: hand.js >> polyfil for touch
  • CSS transforms and transitions: use them… client side hardware is fast!
  • Timer + feedback can be confusing: be sure it’s the right thing to do for the app because use of timer to change a UI element is non-obvious
  • If you do use the timer to alter a UI element, constant feedback is crucial to keep the user in a non-confused state (to the degree that’s possible in the first place)
  • Feedback should make it obvious when a gesture hits the threshold to activate the functionality as well as to validate when the user backed out of (cancelled) the action
  • “The first 20 times someone users your app they don’t know how the UI works.”
  • Q: Is there feedback on commit?
  • Q: Is the interaction learnable?

Second session: Making Rich Data Apps with BreezeJS

  • Speaker has been programming since VB1, Windows 3.1 (not 3.11, thank you)
  • Breeze supports Angular, Backbone, and Knockout
  • Manages and tracks data changes
  • Supports relationships (child/grandchild)
  • Allows linq-style queries
  • Installs from NuGet (there’s a trend to this…)
  • Supports offline data (this is the selling point to this, IMO)
  • Breeze needs the data metadata first — you need to have a metadata endpoint so that Breeze can hydrate it’s data model (this is getting less interesting now, IMO)
  • Register BreezePreStart: routing
  • HotTowel SPA: (uses Durandal, KC, Breeze, Toastr, MomentJS)
  • AutoMapper (install package AutoMapper — not NuGet?)
  • If nothing else: the quick overview of AutoMapper pulled this talk out of the crapper for me.  As soon as he said you have to provide a metadata endpoint I was less interested in this; I would rather define a model and use local storage than make a json call just for metadata.  The discussion of AutoMapper, however, was awesome.
  • q.js — promises library
  • logger.js — sounds interesting, requires more research.  Logging errors is a good use of browser-side data persistence.  By the time you’ve got an error you cannot rely on being able to ship the error details to the server.
  • This is yet another speaker who says “goo-id”

Third Session: Build an MVC eCommerce Site in 5 Minutes

  • Uhm… this schmuck is doing product placement for an open source eCommerce app which is about 18 months behind the technology curve.  Why not do a talk on DotNetNuke 1.0 (the VB.NET version?)
  • “Plugins for nopCommerce might not be functional” — and this was said about payment gateways!
  • EJECT!
  • At this point I left this session and headed over to the main ballroom where there was a round-table discussion about how to make KCDC15 more awesomer.

Fourth session: Service Patterns in AngularJS

  • Speaker literally said: “I literally spend most of my day doing…”
  • Angular components: Modules, Services, Controllers, Directives, Filters
  • Modules: the container for other components; these are not loaded async — you have to have require.js for that
  • Services: custom objects shared across the app. There are injectable singletons.
  • DI in JS: supports tesability; discourages global vars allows for complex config scenarios
  • $injector variable in Angular
  • Angular has its own caching component
  • Controllers: services are injected into controllers
  • Angular does not have a model framework (but Ember does!)
  • “Angular is a framework on which to build other frameworks” — that’s an interesting quote and one I want to research more… I can see this as being either good or bad depending on the scenario
  • Someone mentioned that Ember’s router is better than Angulars… I will discuss this Friday
  • ‘Twas mentioned several times that Angular 2.0 is likely to come out this year, and there will be LOTS of breaking changes to Angular current.  Sounds like Python 2.x/3.x to me: there is going to be parallel support to Angular 1.x (possibly a fork? OSSers are notorious for doing this) and development/extension of Angular 2.x.  Should be fun for all for the Angular True Believers!

Fifth session: Intro to Powershell

  • F7 gives a menu of previous commands
  • “standard command line commands” work in PS as aliases
  • Aliases: most linux shell commands are supported via aliaes
  • PS commands take the “verb-noun” pattern
  • “Get-command -noun service” will list out the cmdlets ending in -service
  • “Get-command -verb Get” like above but for cmdlets starting with “Get” — the point being that the concept of noun and verb is core to PS and you can search for cmdlets using this concept
  • Help is very useful
  • Interesting parameters: -Whatif (trial run) -Confirm -Verbose -Debug (can call into .NET code in debug mode using this param)
  • Everything in PS is an object
  • You can export to CSV
  • Get-PSProvider
  • “Get-Childitem -Recurse -File | {do stuff}” this will find all files in the current and descending directories and {do stuff} to it.  “Get-childitem” is aliased with “dir”
  • PoshGit PS + Git
  • ScriptCS: PS + CSharp
  • Chocolaty: PS + NuGet for windows app management

Sixth session: Pragmatic Software Development: Curing the Architecture Astronaut

  • Architectural astronauts speak in absolutes, are very sure they are right, and cannot be negotiated with
  • “Anyone can design a bridge that stands; it takes an engineer to design a bridge that barely stands.”
  • Be pragmatic: practical, sensible
  • Two goals: context and levels
  • Context: pragmatic, simplicity, timelines
  • Levels: contrast extremes, simple/complex
  • “For some people and teams, TDD is fast.”
  • I wanted to ask the speaker: What training tends to yield the best gains in productivity for a development team?
  • “We are paid to deliver solutions, not to write code per se.”
  • Parkinson’s Law: work expands to fill the available time.
  • Simplicity: the art of maximizing the work not done.
  • Recommended: Extreme Programming blog
  • Lean principles
  • Book recommendation: The Lean Startup
  • Minimum viable product
  • OutlierDevelopment.com (link doesn’t work… I mis-wrote it?)
  • Deadline sanity predicts… I didn’t copy all of that phrase down before he changed slides. Dangit!
  • In a small app: methods are layers.
  • Active Record Pattern: Objects saturate and persist themselves.
  • Book: Domain Driven Design — free at InfoQ, not free at Amazon
  • My comment on this talk: To the question of “Is it better to design quick and dirty versus properly enterprised and layered from the go” the answer is the former.  Consider Facebook: it was built and expanded quickly with PHP and MySQL. Once they became big and received venture funding, they hired hundreds of PhDs to mitigate the fact that they were based on PHP and MySQL.  Because they had succeeded they had this opportunity whereas if they spent the time to do it “enterprise perfect” they would still be in their Harvard dorm room writing EJB specs instead of rapidly building value.