Working Mouse

In November 2016, I was hired by WorkingMouse as a Designer. WorkingMouse is an application services business. They build applications across multiple devices with hybrid apps. WorkingMouse utilises code bots to work with their development teams in efficiently producing their projects efficiently. These code bots are built and maintained by the sister company, Codebots.

During my time there I was able to work with numerous teams and projects. One day I would be designing pull up banners, another I would be assisting developers to design API call builders. I would assist and mentor other designers in how best to style and design out their projects.

Some of the projects, tasks and accomplishments during my tenure at WorkingMouse include:

  • Establishing Sass as the preprocessor of choice
  • Codifying the first branding style guide for the WorkingMouse (Including giving the titular mouse the name AstroMouse)
  • Designing new back-end system for Lampbot, the premier bot used by WorkingMouse
  • UX Flows, UI Kits and Prototypes to build out these design systems
  • Designing new capabilities for Lampbot and it’s users, including Drag & Drop API call builders
  • Internal Presentations about styling and stress-mitigation
  • UI Designs for prospective and incoming clients
  • Robust documentation for new and existing designers for Sass and style implementation.

The culture of Working Mouse aligned with agile, iterative development through model driven development. While I was able to create UI designs and UX flows, I would also be tackling how best teams of designers and developers would work, by fostering clear communication and greater understanding of each parties skill sets.

About a year into my time at WorkingMouse, I officially moved across to Codebots and was the designer for the Lampbot Team.

WorkingMouse 404

Client Work

As most of my time was spent working on the more expansive projects (Lampbot & Codebots) I working on client projects on an ad hoc basis. This meant that I would jump onto projects where deadlines began to loom, or the client needed to be mediated in order to keep projects on course.

Aside from running assistance I would flex my visual and ui designs with potential clients in the initial meeting with them, when the project was moved through to scoping, I would do handoffs with the development team. Here is a collection of the work I did and a brief explanation. (Note all names are taken out of these projects and will be referred to in abstract)

Inspection Application

This project would allow safety inspectors to perform routine inspections on products and properties that would generate risk ratings. This project was taken to scope and development.

Performance Tracker

The client came to us wanting to make a performance tracker for car enthusiasts and the tracks that they drive on. The application would be a Strava but for car enthusiasts. This project was taken on board into development where multiple applications would be made.

Asset Management Application

The brief for this was a asset management portal that would be coupled with a mobile app where physical inspections could be made on the asset before it could be used. This would ensure compliance and safety for the end users of the assets. This project is still waiting on client funding to move forward.

Lead Generation Video Application

For business professional of all walks of life, this project would utilise video conferencing and chat technologies to allow lead generation between professional communities. Think Professional Networking Meetups via video conferencing. This project did not move forward due to funding.

Lampbot was the premier code bot that is used by Codebots and WorkingMouse. It is built on the LAMP stack and using Backbone Marionette.

Working on Lampbot meant I would be doing the following tasks:

  • Improving Lampbot's design and development.
  • Codifying the existing elements of Lampbot and write up it's documentation
  • Improve and assist with new procedures

Updating Legacy

Lampbot is over 5 years old and did not have a specific team working on it for a few years. The time my team was aligned with Lampbot, there were many developers who had built additions to Lampbot but had not done the sufficient documentation. In order to better understand the bot I would revise and redefine many parts of Lampbot and in the vairous locations that WorkingMouse and Lampbot resided I had the LampWall, which was a wall dedicated to the pattern library of Lampbot.

This assisted in the process of building out the MetaModel shapes that would be used in the Diagram Editor.

With this research and documentation done (though I would continue this research and documentation until I left the company) I would be able to build out new ways in how Lampbot presented itself. Much like the codebase the administration portal for all Lampbot project was gather dust and needed to be redesigned in order to allow greater usage by the WorkingMouse clients.

This was given the code name LMUI (Lightning Muffin User Interface... I understand that this may create more questions than it answers.)

Within Lampbot you can give applications greater functionality with 'Behaviours', at the time we had behaviours (at the time called capabilities) for Documents and Questions, for workflows, timelines, etc.

UX Flow for the Documents Capability

UX FLow for Documents

I came up with a general color theme to base the designs but outside of that I would keep my screens and flows lofi, more wireframes than anything. I had decided this as development for this would not be for quiet some time (These designs would have been finished around Feb 2017 and are only now being developed)

Building out new Behaviours

When behaviours weren't being created within client projects, I would be the one who would design them out. For example, we needed a new way to create API calls, not just for developers but for anyone who was tech savvy enough to know what they were.

Early Sketches for The API Behaviours

We would use the scratch programming language in order to create API calls out of 'puzzle pieces'. So with this 'solution first' approach I went on to create the pieces using Google's Blockly. Proving that this could be done with the language I would then interview developers to greater understand API Calls and how they use them. This would then lead to exploring other programs like Postmate to identify what they do right and where tension lies.

With that I used the existing Lampbot admin style (Note: not the one that I had designed) to build out the ux flows for this behaviour.

UX Flow for API Capabilities

Implementing new ways to work

Outside of the UX/UI design work I successfully transferred the company from using LESS as their CSS extension to Sass and worked with all new designers (At the time of joining there were 4 designers (including myself), at the highest point, there were 11 designers) in how best to use Lampbot and implement their designs through it. The Lampbot team devised the Funnel Style Structure that we would use in order make designers better able to code.

This would then move towards the Style Implementation Guide and a Design System Language that would be built into the Codebots Library Section.

This built upon my desire to teach and mentor others and give me opportunity to build those skills.

Like many of my tasks and accomplishments during my time at working mouse, I was very self starting, I initiated various processes and procedures in how many designers worked, one of which was bringing about CSS, the pre processing extension for CSS. Previously, though you there was less less was being used not particularly well as it was early, just getting started started off with knowing that I could well from the barest I would be able to do media queries far easier in Sass. As my prior knowledge and understanding allowed me to understand I quickly devised ways of us being able to change over to assess and be able to put that within our completion process.

Snapshot of the Style Implementation Guide

This was working with developers and making sure that that would be able to be put across and that there was a succession plan. So if any old projects were being reused, or worked upon again, that they could be updated to the new Sass as efficiently as possible. Once we had done that I took it upon myself to train many others in how to use cess properly. I did a variety of internal talks about what's asked was, how you could use it, how it can be best utilized. And one of the standpoints of using this extension, what's been out of that was I nearly 10,000 word guideline, or that is called the style implementation guidelines. This was in part, I way for me to make my training of others more efficient, so that they could call upon that that document whenever they required it, when, even if I wasn't there, which would come in handy when I decided that I would no longer be working at work mouse. So I broke the style fermentation guidelines off into three parts, the Sass living, which was to do with a Sass language theory, this was going over what Sass was the parts of Sass.

Excerpt from Variables section

Variables allow us to reuse values of high repetition. If you are constantly writing out the same color, size, or border value you should instead use a variable in its place. Variables lend themselves to the DRY (Don't Repeat Yourself) methodology and rapid iteration.

To illustrate this, let's look at this example: Joan's online shopping (password and username reuse stands in for class and variable reuse in a style sheet).

Joan shops through many different websites, and all the sites require a username and a unique password. She has the username no2patriarch690 - this is her alias and represents her. Every time she uses this username, she refers to Joan herself.

This example stands in for styling since the username can be thought of as a variable. It is the same value (no2partriarch690) used in multiple sites (sites are our selectors).

And speaking about it in plain speech. Previously, I had had trouble in collecting and gaining the knowledge of what all the parts of Sass that were and how best to use them. So I decided to talk about that as a refresher course for myself, and to allow others to get up to speed faster than I could. The next part was, was called into the wild. Now, these were rules to follow when you were styling. This was like, you know, the formatting and syntax how you would state the naming conventions that you would use RGB RGB a instead of hex or hater cell, and then how to structure out your Sass by grouping logical terms. Putting in your includes first, sorry, Your extends first year includes next and the process of how to do that then went into within this I went into vertical rhythm and a lot of type of graphics theory and how you can best use that my last part was an understanding and concepts of how the styles structure would be used in working mouse. To put it briefly there was a funnel style structure where global styles would have components would be passed down through different levels.

When it got to an application level, it would then be split into a tile view components and elements sections, each one of them housing the smaller effects so a element would be included in a component component would be included in I view and a tile would be included in a view would be included in a time here, I would also talk about some of my experimental things, the ways that we would be doing breakpoint manages some boilerplate efficiency mix since these would be general slice of life nice to haves with all of this you should be able to work through the guide be able to call upon the guide when you needed to and then from there be able to makes the most of your projects.