Archive for the 'Software development' category

A swan song for 2012 and WPF

January 1, 2013 10:08 pm

I intended this to be my fifth and last post of 2012. Life intervened, and it turns out this will be my first post of 2013 instead. Blogging obviously took a back seat to other things last year. Sadly (seen from a certain perspective), I spent a lot of my time this past year reading that incredible time-sink, Twitter. I don’t follow many people, but the ones I follow always have something interesting in their streams. Another thing I spent a lot of time on, it seems, was working on a couple of Windows Phone apps and participating in local events around Windows Phone. But what really took up the bulk of my time at the beginning of the year was a project at work. And that’s what I will spend some time on now.

image

(A screenshot of HP Connected Backup running with a mock UI)

With the launch of Windows 8, HP has developed a more consumer-friendly version of the former Autonomy / Iron Mountain Connected Backup software, called HP Connected Backup. This is just one of the areas where HP is taking advantage of Autonomy’s technology and infrastructure, despite all the acquisition hoopla of late. I was closely involved in the implementation of the UI rewrite. The original Connected Backup software used a Java-based UI and was mostly offered for business and enterprise customers, and the user interface needed to change to be more consumer-friendly. As it happened, someone else made the decision that the UI should be implemented in WPF, still my favorite UI software technology stack. My involvement started when it became clear that the nature of the work was more complicated than the team working on the product had enough experience to pull off.

I had just finished work on another product that ended up only shipping via HP’s support website (called HP Quick Start, a tool for Windows 8 similar to Samsung’s S Launcher, now apparently renamed to Quick Starter; incidentally, there’s a really interesting story about why HP Quick Start didn’t ship, but that needs to be told in 10 years or so, not now). A colleague and I went to Austin, TX to meet with the Interaction/UI design company so I could learn about the amount and kind of work to be done. Their technical team had already started working with the HP development team in the Boston, MA area, and I got set up to work with them remotely as well. Some time after getting my feet wet in the codebase that had already been built (with a great M-V-VM foundation), and working with the Boston team over the phone, another colleague and I visited the team in Boston to start our collaboration for real. We stayed for about a week and got a few things done while we were there, but more importantly, we got to know the people on the team, and they got to know us a bit.

After returning from Boston, the real work began. I participated in daily stand-up meetings via phone. Because of the three hour time difference, I then had a few hours of opportunity to work while the remote team was available for questions and collaboration, and then I would continue working on my own, mostly from home. At the end of my day, I’d have the codebase pretty much to myself, so I didn’t have to worry too much about conflicting code check-ins.

Apart from looking at deliveries from the design house and making sure that everything from them was working as expected, I also built and customized many of the key UI components that were needed for the product. Let me run through just a few.

The tab control for the settings UI

image

The tab control work was mostly a job of cutting apart the Photoshop files from the design firm and fitting them into a styled TabControl/TabItem combo. The trickiest part was adjusting the transparency of the photoshop layers to make the transitions from tab to tab look right.

The UI that indicates file version numbers in the backup set

image

This control is based on heavy customization of the stock WPF DataGrid control with intricate interception of routed events and some complex visual tree trickery to get the interaction with the checkboxes and expansion/collapsing just right. Not to mention the view model construction, mapping the data to the actual backup information from the cloud (the data model).

The “accordion” control for the main UI

image

image

The accordion control is based on the WPF toolkit from February 2010, which contains an experimental implementation of such a beast. It was difficult to customize because it isn’t well documented and has a bunch of built-in behavior that we didn’t want. Not only did this require customizing the toolkit accordion’s styles, I also ended up building custom templates for the way the elements in the headers needed to switch appearance between the expanded vs. collapsed state. This was one of the last things to be finalized on the product. It was a very look-bound control to begin with, and it had a few bugs that were impossible to fix easily by modifying the source code.

The top header with the promotional offer

image

The offer header wasn’t too much work, except in the area of making it appear and disappear under the right circumstances (you don’t want it to show once a customer has subscribed, but you want it to show up again some time before a subscription expires). If I remember correctly (it was a while ago now), I even dug into writing some of the necessary async cloud client code that could retrieve the offer information from HP’s Connected cloud services. Because the final design deviated from what was delivered by the design firm, I actually ended up iterating on the visuals quite a bit with our Product Owner to arrive at something that was acceptable.

The “spinner” control and assets

image

Many parts of the UI are dependent on fetching information from the cloud, which can take a while. In these instances, it’s common to display a form of wait indicator to let the user know that something is happening. We had a control for such a wait indicator from previous products, so I didn’t need to create it from scratch, but the visuals for this control were, of course, new. Since the control uses a “flipbook” animation style (it renders a new image rapidly enough to give the impression of movement), I needed to create all the rotated snapshots for the flipbook to go through. This involved using Image Magick and a bunch of command-line scripting to automatically rotate and crop the original source image. Since we needed three different sizes of the spinner, I actually ended up modifying the existing control somewhat more than I thought, and created multiple sets of flipbook images via the Image Magick scripts I created.

The scrollbar assets

image

During usability studies it became apparent that our design firm had been – let’s say – “optimistic” on the size of the scrollbars that the UI needed. It turned out they were too hard for people to notice and use (i.e. too small). So I had to modify the underlying visual assets (Photoshop files again) without their help and adjust the scrollbar styles to accommodate the new, bigger parts.

Templates for dialog boxes

image

As part of being responsible for the overall translation of the wireframes and visuals from our design partner firm into real code, I needed to make sure our various dialog boxes were presented with a consistent style. Since there were too many dialogs for me to work on directly, I created sketches of guidelines for the team to use when they needed to work out a new dialog.

Quick Tips usability aid

image

image

image

image

I mentioned earlier that we conducted usability studies on the product. By the time we had enough of the product ready for testing, we found that the accordion design of the main UI was not as usable as we had hoped. Even with lots of tweaks to the original visual design cues/clues, people found the two panels of the accordion too difficult to use. I had toyed with the idea to integrate a tutorial of sorts into many of the products I’ve worked on in the past, but never seemed to have an opportunity to do something about it. Well, this time, I decided to take the time. I started implementing the idea and showed prototype screenshots to our usability lead. He liked the concept, and helped me work with our Product Owner to incorporate the idea into the final, shipping code, even though it was close to shipping time. We ended up naming this “Quick Tips”. WPF’s ability to layer UI elements on top of each other made the implementation relatively simple. One part that I’m quite proud of having been able to incorporate into Quick Tips was the ability to operate the UI from code, using WPF’s UI Automation framework. This was something I had wanted to work with ever since I attended the first sessions on this when WPF was unveiled as “Avalon/WinFX” at Microsoft’s PDC 2005. I was quite impressed with the capabilities of the platform in this area. It was relatively straightforward to open and close the accordion as needed to have tips pop up in the right context, etc. The only thing that was a bit tricky was to open up the help context menu and have it stay open with the “Quick Tips” menu item highlighted.

This is just a quick tour of a part of the work that was involved in creating HP Connected Backup. I’ve focused on my work, since that’s what I know best. The larger team worked on many, many more aspects of the product, not the least of which is, of course, readying the backend infrastructure for a consumer-level product and creating a UI for entering subscription and billing information. A part of the product I haven’t touched on at all is the subscription wizard, a standalone app that brought other UI challenges with it, and that walks the customer through the steps of creating an account on HP’s cloud systems and preparing the local system for backup of the customer’s data. This app required quite a bit of tweaking from the original design.

WPF riding into the sunset?

During the work with the accordion control I took a look at the WPF toolkit, since it had such a control in an “experimental” stage. “Experimental” – yeah, no kidding! After much fighting to get it to look the way it needed to look (the WPF toolkit accordion control is not “lookless” like most WPF controls), it became obvious that the version of the control in the “binaries” was different from the version in the source code, so modifying the source code to fix certain bugs was impossible. So I had to resign myself to re-styling much of the control and creating ugly, hacky workarounds for bugs I found.

And this is where my swan song for WPF starts. It seems pretty clear that Microsoft has completely de-invested from carrying WPF forward through their past community efforts. Yes, there’s been a lot of investment in WPF 4.5, but that seems to be about the end of the line. The WPF toolkit was supposed to be a vehicle for taking feedback from the community, developing something in response, refining it, and eventually integrating that into the platform. I think that’s how the calendar control in WPF came about, as well as many other things. The last release of the WPF toolkit was in February of 2010, almost three years ago. Apparently, and I’m guessing here, the work on Windows 8 took a lot of the “steam” out of WPF. The focus was put on developing the XAML platform for Windows 8 “Store Apps”. And it’s been quite detrimental to WPF. From my perspective, WPF’s problem lies in the fact that many of the visionaries behind the original concept are no longer involved in the product. It may very well be that WPF is a mature technology by now (although some people see it as not having fulfilled its promise by a long shot), but leaving it in maintenance mode seems to me to be stopping before you’re really “done done”. Such a pity to see a platform with such incredible potential being wasted for whatever reasons.

Windows 8 XAML

Finally, a small rant on Windows 8 XAML: Compared to WPF, the Windows 8 XAML platform is clearly a “V1” product. It’s almost embarrassing how much of the power of WPF is missing from the Windows 8 XAML platform. I can only point to a few things off the top of my head, but I’m sure you can find many references elsewhere. There’s no tiling Image Brush. No Radial Gradient brush. A lot of the built-in controls are laden with “fast and fluid” behavior, such as built-in transitions, that are very cumbersome to remove or alter. The data binding mechanisms are primitive compared to WPF. Having worked with this new platform for a little while now (a topic for another post, perhaps), I think I can say that I’m disappointed. It’s hard to live up to the power of WPF. I hope Microsoft will get there eventually and I hope WPF will come back “from the dead” now that Windows 8 is here.

Batch download BUILD 2012 videos

November 4, 2012 10:30 am

I didn’t get to go to //build this year (sniff), so I’m going to download a bunch of session recordings for offline viewing.

One way to do this is to use a PowerShell script (I found one here, based on this).

Last year, I just used the script as it was. This time, I’ve modified the  the script code so it also creates a “sidecar” file with the session title and summary:

 1: cd "C:\build2012"

 2: [Environment]::CurrentDirectory=(Get-Location -PSProvider FileSystem).ProviderPath

 3: $a = ([xml](new-object net.webclient).downloadstring("http://channel9.msdn.com/Events/Build/2012/RSS/mp4"))

 4: $a.rss.channel.item | foreach {

 5:     $url = New-Object System.Uri($_.enclosure.url)

 6:     $file = $url.Segments[-1]

 7:     $file

 8:

 9:     $linkurl = New-Object System.Uri($_.link)

 10:     $session = $linkurl.Segments[-1]

 11:

 12:     $descfile = $session + " - " + $_.title + ".txt"

 13:     $descfile = $descfile.Replace(':', '_')

 14:     $descfile

 15:     $_.summary

 16:     if (!(test-path $descfile))

 17:     {

 18:         New-Item -ItemType file -Name $descfile

 19:         Add-Content -Path $descfile -Value $_.summary

 20:     }

 21:     if (!(test-path $file))

 22:     {

 23:         (New-Object System.Net.WebClient).DownloadFile($url, $file)

 24:     }

 25: }

As before, you may not want all the videos. So you can do this with the string in line 3:

http://channel9.msdn.com/Events/Build/2012/RSS/mp4?t=windows-phone

The available filters (for the t parameter) are:

.NET
Advertising
Analytics
Application-Lifecycle-Management
ASP.NET
C/C++
C++
Cloud
Contracts
Data
Design
Device-apps
DirectX
Gaming
Graphics
Hadoop
HTML5
Internet-Explorer-10
JavaScript
Keynote
Kinect
LightSwitch
Line-of-business
Localization
Media
Microsoft-8
Microsoft-design-language
Networking
Office
Performance
Reading
SharePoint
Shopping
Team-Foundation-Server
Testing
Tiles
Touch
TypeScript
User-Interaction
UX
Visual-Studio
Windows-8
Windows-Azure
Windows-Phone
Windows-Phone-Apps
Windows-Runtime
Windows-Server
Windows-Store
Windows-Store-app
Windows-Store-apps
WinJS
XAML
Xbox

If you’re just interested in the slides, use a query like this:

http://channel9.msdn.com/Events/Build/2012/RSS/slides

In general, the query can be constructed like this:

http://channel9.msdn.com/Events/Build/2012/RSS/
[type]?t=[tag]&term=[free text]

Where [type] can be one of: wmv, wmvhigh, mp4, slides

You can add multiple t arguments.

My third Windows Phone 7 app, FotoMovr, featured in Marketplace

April 24, 2012 10:38 pm

Thanks to some awesome work from my partner in crime at Cricketsoft, Tom Allen, our co-developed app, FotoMovr is featured in the Windows Phone Marketplace today. Both on the phone, the Marketplace website, and in the Zune client. Here’s some evidence:

IMG_5752

That’s me holding up my phone, and in the background the emulator running the app. Incidentally, this picture was taken at the Silicon Valley Windows Phone Meetup, where Tom and I gave a short talk this evening about the app and the support we’ve received from Microsoft while developing it.

 

image

The Marketplace section of windowsphone.com.

 

image

And that’s the Zune Apps Marketplace page, which I gather has just been disabled, so I was really lucky to get this screenshot at the last minute.

Fun stuff! Please check out the app, and also my other two apps, “Open ” and “Countdown”, which I see just got a five star rating from a kind soul for the latest version. My friend Tom has another app in the Marketplace as well, called “Good Morning” aka. “GMSV EzReader”. A great little app that makes reading the Good Morning Silicon Valley blog from the San Jose Mercury News really nice on Windows Phone.

Why Agile software development works

February 14, 2012 11:30 pm

I’ve been part of teams that practice Agile software development methods for quite a while now. My own team at work has been doing things in an agile manner since about 2008. Before that I was a co-founder of the Agile SIG (Special Interest Group) at work for several years, attempting to bring agile into the organization from the grassroots level. I’ve been trained for the role of Scrum Master by Ken Schwaber and Jeff McKenna. I started a group of retrospective facilitators at work as well, in the hopes of turning the organization I was part of into a more consciously learning organization. Before the job at my current company, I practiced eXtreme Programming in a startup. This is (I think) my first blog post exploring some aspect of Agile software development methods.

Over the years I’ve come to realize what it is about agile that makes it work. Agile is basically a mitigation strategy/technology that addresses the human tendency to fail at communicating effectively. Let’s look at this from the perspective of a model I learned about in high school from my language arts teacher – the basic human communication model. This model comes in various forms, but I like the one from my high school years. It’s one of the few things that have stuck with me from that time:

image

The Sender and Receiver in this case are people (although this model applies to pretty much any communication situation and is used in computer-communication model discussions as well). The Context on each side is complex. It’s made up of a person’s knowledge, cultural upbringing, state of mind, experience, financial situation, family circumstances, and many, many other factors. The Sender intends to convey a Message to the Receiver and the only way to do so is by Encoding the Message (in a way that the Sender hopes the Receiver will be able to Decode) and to pick a Channel for transmitting the Message. The Sender’s only way to verify if the Message reached the Receiver is by some Feedback mechanism, which actually just reverses the situation of the diagram. There are lots of ways that the communication can break down. For example, the Sender might pick an Encoding the Receiver isn’t able to Decode; the Channel might garble the Message so it becomes unrecognizable; or the Receiver might be in a Context that prevents the Message from being Decoded properly. Other communication breakdowns involve the Sender making unstated assumptions about the Receiver’s Context, the Sender picking a Channel that is inappropriate for carrying all the meaning necessary for Decoding the Message, or the Receiver not being receptive to the Message coming through the Channel.

When building software, the central thing we do is to turn ideas in our head into instructions for a computer to execute. If this were a solitary exercise, there wouldn’t be much of a problem: you have an idea; you think about how to translate it into something the computer can do, taking into consideration your skills, the computer environment, your choice of software technology stack, programming language, experience, etc., etc.; you sit down for a few hours, weeks or months to design, write code, test, deploy – and you’re done! In terms of human communication there is none, so the model doesn’t really come into play.

The trouble doesn’t start until you’re working on something that takes more than one person to accomplish in a reasonable amount of time. Unfortunately, most things undertaken in software these days are of this nature. This means several things. One, there will be human communication going on! Two, the kinds of communication will take many different forms and concern many different topics. And now we’re squarely in the domain of the communication model.

Just thinking of the number and kinds of things that will need to be communicated between people can make your head spin:

  • How many features will the software have?
  • What are the features?
  • How will we know that a feature is done?
  • What technologies will we choose to implement the software?
  • What computing systems will we support?
  • How will we construct the software so it is robust enough, yet easy to change in unforeseen ways?
  • What are the major parts of the software?
  • How will the parts communicate?
  • Will the user be able to understand it and use it as intended?
  • Will we be able to deliver the software on time?
  • What does on time mean?

And these are just some technical questions. There are others as well, more business related:

  • Will the software have value to customers and users?
  • Will the customer pay for it?
  • How much will the customer pay?
  • Will the customer be made mode productive by using the software?
  • How will we deliver the software to the customer?
  • How will we know if we’re building the right thing?
  • How will a customer be able to provide feedback on the software?

Pulling off almost any kind of software effort requires answers to these questions, and more. The nature of software development is one of producing ideas and mental constructs that can be turned into instructions for a computer to execute. If more than one person is involved in this activity, those ideas and mental constructs have to make their way from one person’s brain to another’s, so the people can collaborate to get the software built within some time limit. Agile software development methods bring to this process more formal opportunities for people to interact, increasing the likelihood of this communication happening  regularly and at varying levels of complexity, timescale and team composition.

Let’s take Scrum as an example. Scrum sets up a framework for communication and feedback like this (from high level/long timescale to low level/short timescale):

  • At the Sprint level (usually every 2 weeks these days, but Scrum originally used 30 days) –
    Sprint planning/review meetings and Sprint retrospectives. These provide opportunities for medium-term communication and feedback on the production of a usable increment of software functionality.
  • At the Backlog grooming level (usually at least once a week, but not specified by Scrum) –
    An opportunity for communication and feedback about user story details that concern upcoming sprints.
  • At the Daily Scrum level (every day at the same time) –
    What happened yesterday, what will happen today, what’s getting in the way? This is an opportunity to quickly gather feedback and communicate about nitty-gritty day-to-day details.

Scrum’s official rules (found in the Scrum Guide) were recently updated (in July and October of 2011) to allow for more freedom in selecting practices and experimenting with new things. So, as of the latest edition of the Scrum Guide, Release Planning is no longer part of the official Scrum rules. If it had been, I would have argued that Release Planning and the Release Retrospective provide the highest level of overall communication and feedback loop that Scrum puts in place. Since many people still use Release Planning as a tool, I think the point still holds.

Many people mix in good technical practices as well, which add things like:

  • Pair programming –
    Instant, real time communication and feedback on the construction of ideas and expression of those ideas in code.
  • Continuous integration –
    Feedback on code quality, feature readiness, etc. on a daily basis or more often.
  • User story estimation (part of Sprint planning) –
    Feedback and learning about what a software feature is supposed to do, how it will be implemented, what its acceptance criteria are, etc. Often summarized by a relative size called “story points” based on the Fibonacci series of numbers, which are useful because people are somewhat better at judging relative sizes than absolute sizes.

Human communication tends to break down in unexpected ways. Agile software methods give people plenty of opportunities to communicate and get feedback, helping to mitigate the breakdowns that occur in the complex context of team-based software development.