Loading
Build in Progress Mobile Process Map UI

Build in Progress Mobile Process Map UI

by ryanprinster scientiffic vcjones | updated October 20, 2015

Documentation of creating the process map interfaces on mobile to visualize your Build in Progress projects!

Clothing_icon
Electronics_icon

0

Hey there! This is Victoria and Ryan, and this summer we are helping to improve and further develop the Build in Progress mobile applications on Android and iOS platforms.

We decided it would be fun to document the development process, everything from our learning curves to the current state of the project, from our most frustrating problems (there were a lot) to our most innovative solutions (not nearly as many).  We'll be sharing how we designed the process map for the mobile app to keep the spirit of the Build in Progress branching interface.  Hopefully you find it interesting, and remember, both apps are always quite literally a build in progress, so if you have better solutions to our problems, feel free to let us know!

 

August 10, 2015 at 11:56 AM
Created by ryanprinster
Comments (0)

We want you to have complete control over every facet of your project like you might on the website. Right now, our project editor is missing one big thing: the labels! 

But how were we to separate them from the steps? We wanted to organize them in a way such that the steps and labels were clearly seperate entities, however the steps already took up most of the current view. One idea was to separate the table into sections, like the contacts list on your iPhone. Another was to just throw the labels in with the steps, and use different colors to distinguish between the two. 

Our first mockup ended up being a swiping interface; the current table of steps would be for the most part untouched, but a user could swipe right or left to view another table containing the labels. 

Although a seemingly elegant solution, there were a few problems. First, from viewing the steps, there isn't much more than the little edge on the side poking out that hints you might be able to see the labels. Additionally, Apple documentation says not to put UITableViews in a UIScrollView, by far the easiest way to implement this mockup.

This makes sense, if you think about it. You have a touch or a swipe or whatever on the screen. If it takes place inside two views, one is a subview of the other, but both have functionality, then how might the computer determine which needs which? Although I'm sure, with some clever shortcuts and assumptions, I bet it can be done, although it would not be trivial.

Those problems led us to our next prototype: the buttons (we need a cooler name for that).

 

 

 

August 13, 2015 at 9:52 PM
Created by ryanprinster and vcjones
Comments (0)

August 13, 2015 at 9:53 PM
Created by ryanprinster and vcjones
Comments (0)

Our primary motivations behind including the branching interface iconic of the website were pretty simple: the mobile app lacks the ability to practically visualize and rearrange the steps in a project.

Our secondary concerns regarded usability as well as functionality, while keeping in mind ease of implementation. We wanted the user to experience no abiguity or confusion, while retaining the ability when to add, delete, or rearrange steps.

Through this line of thinking, our first prototype constituted a step-by-step instructional interface. In this, the user selects a step, is walked-through by a series of options and instructions. For instance, the simple prompt of "Where should it go?" implies that the user should next click on another step to preview the potential new layout of the tree.

We also added a spot in the top-right which displays the current step. This, along with imultaneously removing it temporarily from the tree, gives the user the sensation of "holding" the step, and therefore the desire to place it back into the tree.

However, when I began researching how to implement this particular interface, it quickly became clear that this would not be easy to implement using existing iOS resources. It would require quite a bit of UI work, as well as backend to get the tree looking right. Furthermore, coupling iOS functionality with a UIWebView (a window that lets you view web pages) would also be difficult, as there is no easy way to pass data in between the website in the UIWebView and the iOS part of the implementation. Of course, Android would likely be no easier.

This lead us to abandon this prototype, instead in favor of re-using the majority of the code already present on the website.

 

August 13, 2015 at 9:56 PM
Created by ryanprinster
Comments (0)

Our original plan was to develop a viewer and drag-and-drop interface directly in both the Android and iOS apps (written in Java and Objective-C respectively), but we decided to do a quick prototype of a web view to see if we could reuse the process map implementation on the website.  Ideally, we want the mobile app to be as similar to the web interface, so if this works, it'll be the best-case scenario!

I started off by finding an iOS example using WebKit to display webpages in a native iOS app [https://github.com/Leveton/MELBrowser] and edited the styling a bit to remove some of the unnecessary elements (such as the back and forward and refresh buttons).

I then created a new project page route on the website that only displays the process map.  I only have this on the test server currently, but in the future, it'll be viewable by appending "/mobile" at the end of a project page URL.

Then I found a neat library called Jquery UI Touch Punch [http://touchpunch.furf.com/] that converts mouse events to touch events so that you can reuse code you might have written for a desktop browsing experience.  This basically enabled the drag and drop interface on mobile almost completely out of the box by reusing all the code I wrote for jQuery draggable!

After that, it was mostly just styling changes and security details (e.g., only allowing authors of the project to access this new page and edit the process map).  I scale up the process map to fit on different screen sizes so you can view your projects at a comfortable size.  After testing with the BiP UROPs, I also made it so you have to first tap on a step in order to rearrange it – this prevents accidentally rearranging when someone's trying to pan in a particularly busy project.  You can check out a video of this interface above.

But wait!  What happens when a project is really wide?  Panning to view the entire project can be annoying, especially if you want to rearrange steps.  This was the hackiest thing I ended up implementing, but it works. Basically what this involves is finding out how wide a project is and forcing the mobile interface into landscape mode if the project is very wide.  The workflow for this is:

Through the mobile application, I load the project page, for example: 

NSURL *url = [NSURL URLWithString:@"http://secret-bip-test-server.com/projects/200/steps/mobile?auth_token=secret-authentication-token"];

Then on the website side, I created a before_filter to check the width of the tree when this request is received:

before_filter :check_tree_width, only: :mobile

  def check_tree_width
    redirect_to(tree_width: @project.tree_width, auth_token: params[:auth_token]) unless params[:tree_width].present?
  end

So when the app loads the URL, it actually loads a URL with the tree width in the parameters, for example:

http://secret-test-server.com/projects/200/steps/mobile?auth_token=secret-authentication-token&tree_width=12

Then in the app, I check if the tree_width is greater than 10 and force the phone into landscape if it is:

 NSLog(@"website url: %@", [self.webView.URL absoluteString]);
    NSURLComponents *params = [NSURLComponents componentsWithURL:self.webView.URL resolvingAgainstBaseURL:NO];
    NSArray *queryItems = params.queryItems;
    NSLog(@"queryItems: %@", queryItems);
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"name=%@", @"tree_width"];
    NSURLQueryItem *queryItem = [[queryItems filteredArrayUsingPredicate:predicate]
                                 firstObject];
    int tree_width = [queryItem.value intValue];
    NSLog(@"tree_width: %i", tree_width);


    if(tree_width > 10){
        // rotate for wide projects
        NSLog(@"rotating process map");
        [[UIDevice currentDevice] setValue: [NSNumber numberWithInteger: UIInterfaceOrientationLandscapeRight] forKey:@"orientation"];
    }
    

You can see an example of it in the video above.

I'd love to hear your feedback on this if you have any thoughts!

August 14, 2015 at 12:16 PM
Created by scientiffic
Comments (0)

Just like steps, your labels need a screen where you can rename the label or change the label color. Here we've included some drafts of this screen. 

August 25, 2015 at 1:58 PM
Created by vcjones
Comments (0)