Enterprise

Enterprise software interfaces are my passion. Having spent years in consumer I’ve developed an addiction to the challenges of making complex tasks manageable. The point of UX is to connect people to technology in order to get things done. Nowhere is that more imperative and difficult than in enterprise class interface design and implementation.

CloudForge Lockout Mobile App

lo-isoThis is an idea I came up with a year ago but didn’t find the time to make a solid pitch to CollabNet management. I’ve recently taken the time to run through some ideation, explorations, and designs.

Whenever the idea of doing a mobile version of CloudForge came up there was usually a rather lukewarm reaction from he product owners and biz dev. The nature of the service simply did not lend itself to a mobile experience. We’re talking about IT in the cloud which takes a lot of serious decision making, analysis, and careful action. Mobile seemed so “on the go” to an organization with roots in SVN.

There was this one use case, though. Something that came out of the Customer Success department calls. There was a case for making it easier to lockout users when a vendor or employee was no longer on the team. This was the one instance when an admin was out to lunch and suddenly needed to rush back and start locking accounts. I thought that maybe a mobile app that did one thing really well would trump an app that tried to address even half of the options available in CloudForge. What if we made an app that just let you manage access permissions for users? This would address a known user pain point, start moving the service into the mobile space, and start getting the users hungry for more mobile access to CloudForge.

lockout-use-case-1 cloudforge-lockout-value

 


Ideation

Pulled out ye olde wipe board and started throwing out ideas. Yes, I keep a wipe board in my bag at all times. I’ve made the mistake of skipping this step in the past. The sooner I start running into issues, the better.


Information Architecture

lockout mind mapLet’s start getting organized on exactly what this app will do. I broke it down into three main actions; lock, unlock, and reset.

Lock = shut out, no getting in, you’re done!
Unlock = Oops! Ok, you’re not so done.
Reset = Locked out until you reset your credentials… just in case someone knows another user’s credentials. It happens.


Wireframes


What you’re looking at here is a version 2.xx. As I ran the initial wireframes through some guerrilla usability I came across some issues. In fact, I ended up running into a menu selection issue on this version. Lemme know if you see it. 😉


Mock Ups

I tend to think of each step in the UXD process as a further exploration of the previous step. As I’m laying out a mockup I’m still open to feature ideas that did not exist in the wireframes. In this case there are four new ideas on the dashboard that did not exist on the wireframes.

explanation

  1. The “New Locks” feature which would let the admin know that someone locked a user outside of this app.
  2. Ability to hide/show the graphs, the ratio numbers (e.g.: 5/20), etc on the slide out controller.
  3. Displaying the percentage of a node as a graph within the node icon itself. The green areas indicate that less than 50% of the total are locked. When the total hits 50% then the graph goes red. I’m thinking that a third state of yellow is not truly helpful.
  4. A flip out filter control set rests at the bottom right. I like to indicate that something can be swiped. Exploration is great but I still prefer clearly marked functionality with this audience, engineers and product managers.

Redesigning Cloudforge with Lean UX

Cloudforge by CollabNetUI/UX Design and implementation, HTML, CSS, and Javascript all in a RoR & Bootstrap environment.

This was a complete redesign of the entire core application UI/UX. Collabnet Inc was looking to bring their Perl and custom JS based framework into the modern age of rapid application development. Strict SCRUM processes and agile processes.

This “green-field” project was a ton of fun. They had an existing product with thousands of users. Many of those users were major fortune 500 company accounts. We had to come up with a UI/UX that accommodated consumer, enterprise, and contractor user stories.

The end result was night and day compared to the original. Proud of the work we did here with a great team and an amazing manager.

Cloudforge was previously CVSDude

When we walked into the product Collabnet had already owned Codesion (formerly CVSDude) for a year. They had a Perl backend with a custom Javascript client. The assignment was to bring the entire product out of both of those technologies as much as possible, rebrand it, and create and platform that any dev could work in and extend. The lead developer chose Ruby on Rails and while he started building the foundational application I got to work with a hired design firm.

Google ChromeScreenSnapz005Six months later we landed here. The designs from the firm had been dropped, we committed to the Bootstrap look and feel after three full explorations, and most of the application was off of the older platform. We had a new name, a new brand, and new customers.

From a UI/UX stand point the idea was to pull a more consumer experience into the development tool (think what Github did for a terminal tool) without losing credibility with our engineering based customers. We had thousands of existing users that didn’t love the old UI but did know it. We needed to pull them into a new paradigm without shocking them.

I  moved in the more modern approaches to UI, especially mobile paradigms. I got rid of as many checkboxes and drop downs as possible. We needed to step out of the 90’s. While the Bootstrap library was an outside restriction, it did provide us with a great excuse to leave many established but antiquated elements on the cutting room floor. Luckily the team agreed and we ended up with a product that was a major step ahead for Collabnet. In fact, they soon began to adopt many of the patterns and UI elements into their flagship product, Teamforge.

While our visual styles came directly from Twitter Bootstrap, the design patterns on the UI widgets were designated in a living style guide. This allowed engineers to create without the need for a designer at every turn.

Learned skills.

The CloudForge project allowed me to explore some new tools; Bootstrap, JasmineJS, HighchartsJS, Balsamiq Mockups, and MindNode. This was also the first real Lean UX project that was handed to me. Personas, user stories, wireframes, all of it was learned in the fires of live sprints building a real product. I had one hell of a manager.

What would I do differently?

First thing I would suggest is moving into an MVVM framework like Angular or Backbone. I always thought that CVSDude had the right idea about decoupling the UI from the controller and model side but the custom JS… man, that was a monster. Now that the Perl side is gone it would be great to take the final step and move the presentation off of Rails and turn it into a Restful service accessible from mobile, web, etc.

The dashboard seems to be built more for pushing features than for quickly communicating relevant information. Current best practices suggest that dashboards should be more about giving the user information than for being springboards for or containers for actions, purchases, etc. I should have stood my ground more on this but two different product managers wanted more “bells and whistles” and insisted on designing the dashboard themselves.

I’d also pull out a lot of the PNG’s and start using SVG’s. I’ve noticed a lot of anti-aliasing issues as I’ve been revisiting the application after my exit. There’s lots of jaggies on the icons that come from resizing images outside of the 8bit scaling rules. SVG’s would allow them to use any size without worrying about such issues and start playing with low cost animations.

Project Detail 2.1

Project Detail 2.1 is an imagining of iterations on the UI/UX. It uses the updated Bootstrap lib, a more consumer grid layout, and updated iconic treatments.

While we pushed for a more flat design aesthetic, it just did not fit within the short term plan. It would have stood out against the other products in the CollabNet family so we stuck with the beveled look and feel for a lot of widgets.

It would have been nice to create a responsive layout but the owners decided not to focus on mobile. Shame given where all the growth in internet use is and this was really a “manager’s tool”.

Teamforge Orchestrate in Agile

Teamforge Orchestrate

Teamforge Orchestrate keeps track of every commit, build, and deployment a team makes and presents a human readable interface.

Lean UI/UX implementation in a Ruby on Rails front end within a strict SCRUM team environment.

The Orchestrate project brings a consumer grade UI to the automated test/deployment process. It’s a tool for admins and managers to monitor and react to the build process.

This was a six month project with a 10+ person team located in Bellvue, WA. I was brought on after the group realized the need for someone to sit between the lead designer, the product owner, and the rest of the engineering team. We would review and plan before he executed designs. Once they passed review I made them into reality.

Orchestrate Pipeline Builder

Teams can create their on “pipelines” which tell the system which steps are involved in a build or deployment.

The big takeaway for me on this project was the process itself. This was a team comprised of mostly Java engineers turned Ruby on Rails. The group ran a very tight form of Agile, unlike Cloudforge which brought me into the company. We ran scheduled nighty deployments along with automated Jenkins builds with every Git push. If you broke the build you knew it within 30 seconds when someone yelled your name from a dark corner. It was a much more transparent and structured environment and it slapped me into shape. I was forced to learn to write tests because I was forced to break tests as I made change requests.

Orchestrator became a plug in for the Teamforge product as opposed to the original plan of being stand alone. That decision really squelched a lot of the ideas that the team had for a really dynamic and current user interface. We ended up with a solid running application.

Orchestrate Detail View

Each node on the left represents a step in the deployment process. This includes commits, code reviews, build results, etc. There could be anywhere from one to hundreds of steps and the UI has to respond.