Loading
Build in Progress Process Map

Build in Progress Process Map

by scientiffic | updated December 10, 2014

That little view on the left side of this project page (the process map) has gone through a lot of revisions! I'm in the process of developing a new version, so I went back and got pictures of all the previous iterations of the process map and thought it would be nice to share in a project!

Clothing_icon
Electronics_icon

0

That little view on the left side of this project page (the process map) has gone through a lot of revisions!  I'm in the process of developing a new version, so I went back and got pictures of all the previous iterations of the process map and thought it would be nice to share in a project!

September 17, 2013 at 11:12 AM
Comments (2)
This looks like a cool project that will eventually come to fruition what was your motivation in making the project?
over 3 years ago
Thanks! The motivation for the project is to help people share all aspects of creating a design project, including the iterations and missteps along the way.
about 3 years ago

Believe it or not, this was the first iteration ever of the process map (aren't you glad it doesn't look like this!).  I thought it would be important to categorize different types of steps (for example, sketching out a design, fabrication, etc.), which I tried to represent both in different colors and different shapes.  

September 17, 2013 at 11:19 AM
Comments (0)

In my next design, I thought more about categorizing different types of steps.  I designed three different icons: one for hardware, one for electronics, and one for programming.  The idea was to have users add steps to the category the step fell under.  This would enable users to easily see at a glance the type of project it was (e.g., did it focus more on hardware or electronics or software?).  

I liked this idea, but it ended up into some complications.  For example, what happens when you combine different processes in a step?  If you look closely, there are some dots (representing different steps of the process) that have all 3 colors in its outline: I considered these to be "hybrid" steps, or ones that use multiple categories of processes.  

You can clearly see in the second image that representing a design process this way can get really complicated.  

Another disadvantage of this design was that it was hard to know when things occurred.  Eventually, I decided not to go in this direction because I also thought it would constrain the types of projects people would think to share on Build in Progress.  I didn't want users to feel that Build in Progress was only for combinatory hardware, electronics, and programming projects!

September 17, 2013 at 11:24 AM
Comments (0)

With my categorized view, I also played around with the placement of the process map.  I was unsure of how much people would branch, or show different iterations of their process, so I played around with having the process map be horizontal rather than vertical.  I also color coordinated the different types of processes.  Again, this became a problem for steps that used multiple categories of processes–for example, if something involved hardware and software, how would I represent it?  I do like how colorful the design was, though.

September 17, 2013 at 11:25 AM
Comments (0)

My next version looked a bit more like what you see currently (or as of 9/17/13).  I represented each step of the process as a dot and had a text label for the name of the step.  I liked how you could very easily see the topology of the design process in this view, but it didn't give you a good sense of what was going on at each step.  Adding pictures to the different steps really makes a difference, I think.

One interesting part of this design is how "dead-ends" are represented.  I wanted users to be able to show paths that didn't end up working out, so I added an "x" as a placeholder for a "dead-end."  I didn't like the message that this sent, though (one of failure), so I ended up scrapping this part of the design.

Another thing to notice is that in the previous design, you had to click on every step to open up its description.  Isn't it nice that you can view all the step descriptions on the project page now!

September 17, 2013 at 11:28 AM
Comments (0)

In this version of the process map, I finally added images to each step.  I wanted the entire process map to be pannable behind the project description area, so the idea was that you could collapse the project description and just see the process map if you wanted to.  Another interesting part of this feature is the overview in the top left corner: this would allow you to, at a glance, see the entire structure of the process map at once.  I also added a timeline bar at the bottom of the page to indicate that the process was arranged chronologically left to right.  I ended up not going into this direction because it took far too much space (check out the second image!)

September 17, 2013 at 11:41 AM
Comments (0)

I went back to the more condensed view without images for this next iteration.  In this version, I had an explicit branching icon that you could click on to show where you could create a branch (the little grey dotted arrows).  When you hovered over one of the arrows, it would show you a preview of where the step would be created.  At this point, you could click the add new step at the end of the preview branch to add your step.

I also had an add new step button at the end of every branch.  I realized that this would get very cluttered, so I started thinking about other ways to add branches.

Another interesting part of this feature was adding colored branches.  I added the color branches so you could see what steps ended up in the final process.  I wasn't sure how to implement this if someone went back to a previous branch, though (this assumed that the second branch was always the one that the user ended up using).

September 17, 2013 at 11:47 AM
Comments (0)

In my branching interface, I spaced the steps vertically in chronological order (so for example, step 2 would appear lower than step 1 in the process map).  This led to some complications regarding when someone branched multiple times from the same branch (or essentially when a user returns to an existing branch).  I ended up creating a lot of mock ups of what this could look like.  Now that I think about it, I still haven't solved this problem!

September 17, 2013 at 11:54 AM
Comments (0)

I decided to redesign the process map to make it more visual by creating large steps that could have image previews of the different steps.  You can see that I still had buttons to add steps at the end of every branch, but this looked a bit less imposing than before.  This didn't solve the problem of adding branches in between existing steps, though.

September 17, 2013 at 11:56 AM
Comments (0)

This design came out of a meeting I had with Chris, a researcher in my group.  She had the excellent idea of having people drag out a step block to where they wanted it to be placed.  This got rid of the issue of adding the add new step button at the end of every branch.

There are still things I'd like to do to make the Process Map even better, though.  I think it would be great if there were a preview of how the Process Map would change before you drop the Add New Step block.  I'm also thinking about adding tag clouds so users can annotate / mark certain sections of their process (for example, this section is where I was coming up with the design, this section was when I was fabrication the final design, etc.).  

Do you have any suggestions for other things you'd like to see in the process map?  If so, please add it in a comment!

September 17, 2013 at 12:02 PM
Comments (0)

It's been a while since I updated this project, but I've still been thinking a lot about how to change the process map.  Here are some mockups I made in Illustrator.  

These sketches are some explorations into categorizing different parts of the project. I think an important part of making the process map readable is enabling users to get a higher-level view of the project.  Unfortunately, these representations often lose a sense of time, making it harder to know when you worked on different parts of your project.  

I also played around with the idea of having things represented in a sort of pie chart, where time would go clockwise, with all the final steps closest to the center of the circle.  Any branches would then be represented as offsets of segments of the pie.  This can be a little tricky because it means that the branching can only occur off of one step (it would be difficult to represent chains in a branch using this representation).

December 12, 2013 at 11:04 AM
Comments (0)

I'm planning to launch a brand-new interface for project pages.  There are a few key changes I'd like to make

  • removing the "blog" view - the linear arrangement of steps on the right side of the page takes up a lot of space and is ultimately not how I see people using the site.  I'd also like to move away from comparing BiP to a blog.
  • helping people start from images - one of the key insights I had from talking to people who create documentation is that they always start from the images rather than thinking about the "step."  I'd like to make it easier to create a step from images (rather than creating a step and then placing the images in them).
  • a presentation mode - I want to make it easy to share project pages with other people, which I find hard to do with the current design.  I'm planning to introduce a mode specifically designed for presenting designs to others.
  • annotations - I want to enable people to mark up their "process map" so that it's easy to see "dead-ends" and important moments in the process.

I find the process of redesigning the project page a bit daunting but also exciting.  The biggest question I have is what platform to use for the redesign.  Other platforms that I think have a similar feel to what I'd like to create, such as Prezi, are built using Flash, but more modern platforms are using HTML 5 instead.  I also think that Processing.js is a potential option.

Question
What are some Flash alterantives? What can you do in Flash that you can't do in HTML 5?
What I decided
I decided to use HTML 5 instead of Flash since Flash is being phased out.
April 17, 2014 at 11:21 AM
Comments (0)

While I originally liked the idea of having people explicitly move the "New Step" block into their process map each time they created a step, there was as a lot of confusion about doing this.  When I talked to people that were using Build in Progress, many people said the Add New Step drag and drop interface was confusing.  

At the same time, I was redesigning the project page to incorporate a new banner at the top of the page.  Because of scrolling issues, it no longer made sense to have a container for holding the new step.  

To resolve this issue, I decided to create a menu button that allows users to add a new step.  By clicking the "+" button, a new step would automatically be added after the previous step.  

Although this interface is easier to use than the previous design, it has led to many linear designs and does not require the same amount of conscious decision making in the placement of a new step.  I'm trying to figure out a way to balance ease of use while encouraging reflection about placing new steps on the process map.

April 28, 2014 at 1:24 PM
Comments (0)

I decided that a cyclical version of the design process didn't necessarily make sense for Build in Progress because while the steps in a design process can be cyclical (and iterative), it would probably be more difficult to manage programmatically and navigate.

April 28, 2014 at 5:01 PM
Comments (0)

I read this great paper called A Review of Overview+Detail, Zooming, and Focus+Context Interfaces, and it gave me a lot of different ideas for structuring the process map on project pages.  I'll show some mockups I have in branches.

April 28, 2014 at 5:04 PM
Comments (0)

The side-by-side view is essentially what I have now; both the overview, or the process map, and the detail view, or the "blog" portion of the site, are shown side-by-side.  This leads to some clutter on the site, but also makes it easy to scroll vertically through the steps.

Pros:

  • Can visually associate steps in the detail view with the process map through highlighting (the yellow border around corresponding steps in the process map).

Cons:

  • Visually cluttered and thus difficult to navigate.

April 28, 2014 at 5:06 PM
Comments (0)

In the Detail + Overview version of the project page, the user switches between a detail view (with the step description and images) and the overview (the process map).  The process map is always visible, at least in a thumbnail version that can be expanded. 

Pros:

  • enables larger screen real estate for viewing a step or the process map (which can take up the entire screen)

Cons:

  • The process map and detail view exist in separate spaces, which may make it harder for users to see connections between the two.

April 28, 2014 at 5:09 PM
Comments (0)

With the Focus + Context view, users view the detail view embedded in the overview.  The idea behind this interface is that when you click on a step, it expands the step's detail view in place.  There are two options that I've shown in the mocks up:

  1. The other steps in the process map shift to accommodate the expanded step detail view.
  2. The detail view appears as an overlaid window, obscuring some steps in the process map.

I prefer having the entire process map shift to accommodate the enlarged detail view, but this is programmatically harder to do.

Pros:

  • Even with the step detail view shown, you can view where the step fits in the entire process

Cons:

  • Potentially less screen real-estate for the detail view (compared to the Detail + Overview interface)
  • Programmatically the most difficult to implement

Even though this one is the most difficult to implement, I like it the most so far.  One thing you might notice is that with this interface, you can't vertically scroll through the steps like you can with the current "blog" view.  A vague idea I currently have for how to address this issue is to place a vertical timeline on the right side of the screen.  With the timeline, you can drag a slider to expand steps in the order they were created.

April 28, 2014 at 5:13 PM
Comments (0)

I've seen timeline interfaces before (see http://buildinprogress.media.mit.edu/projects/184/steps/3), but after reading the paper Lifelines: Visualizing Personal Histories, I decided to reconsider the option, at least to have something to compare to the Focus + Context options.

In this interface, the "detail view" would be in the center of the page and would be scrollable horizontally.  Below the detail view would be an overview, where the steps would be organized by task.  Markers would exist for each step, placed within the appropriate task.

One option for allowing the user to see even more of the overview would be to enable resizing of the overview section so that it can take up the entire view.

Pros

  • combines detail and overview while allowing rescaling 

Cons

  • the overview gets less space on the page.  
  • it may be more difficult to see iterations than it is with the existing tree structure (one option would be for the users to create a new "task" when they start something over, but I don't have a good idea for a visual link between two related tasks).

April 29, 2014 at 5:06 PM
Comments (0)

One feature that I'm always getting requests for is to add labels to the process map.  I'm currently thinking about an option to add labels into the tree, with options to change the color of the label to indicate different types of annotations.  

For example, a red annotation could be used to highlight a mistake and the reason why a certain branch was abandoned.  A blue label could be used simply as a label to show what different branches indicate.

May 14, 2014 at 11:31 AM
Comments (0)

I've been prototyping the branching interface for some time now and am almost ready to launch the new feature.  

I designed the branch labels so that they wouldn't appear on the right side of the page (since they aren't steps).  But I also needed a way for people to be able to edit the branch labels after having created them.

The first idea I had was to hide the labels on the right side of the page until authors click on them in the process map.  At that point, they would appear on the right with an "edit" button that can be clicked on to edit the name and color of the label (see video above).

After showing this to different people, one person suggested that it was extra work to click on the label on the left and then click the edit button on the right.  She suggested going straight to the edit page right after clicking on the label in the process map.  I decided to prototype this interface too so I could compare them.

May 22, 2014 at 4:36 PM
Comments (0)

I decided to try prototyping a version of the branching interface where you can click on the label directly in the process map to enter the edit page.  I did this by creating a "mask" over the label that appears when you hover over it, along with a pencil icon to suggest that you can edit it by clicking.

After testing out this UI, though, I thought it would be a potential source of confusion that you could click on labels to edit them directly, but clicking on the steps would still scroll to the step on the right (rather than enter the edit page for the right).  I like keeping all the edit buttons consistently on the right side of the page.  

When the branching interface gets launched, I'll be able to indicate with a red label that I decided not to go with this version of the UI!  Stay tuned...

May 22, 2014 at 4:49 PM
Comments (0)

After soliciting feedback from others, I found that people liked the Detail + Overview design the most.  I started to build out the interface in HTML 5 with the help of chrisg, who helped me think about how to draw a tree structure (which involved a lot of math!)

Right now, you can click and drag steps freely and double click on a given step to expand it (which would eventually have all the information you see for a given step, including the step description, images, design files, etc.).  

I'm now working on how to have the steps "snap" to a grid so that they can only be placed in certain positions.  This way, when a person rearranges a step, the tree gets updated as the step is moved around, letting the user know where they're able to create a new connection.

June 9, 2014 at 2:40 PM
Comments (0)

It's been a while since I've shared my progress on designing the new project page, but I have been working on it! 

Right now, I'm focusing my efforts on designing the UI for rearranging steps on a project page.  From watching people rearrange steps on their Build in Progress pages over the past few months, I've consistently seen people drag a step to where they want it to end up.  Currently, you have to drop a step over its parent, which is not the most intuitive thing to do.

I started off constructing the rearranging interface by working with 3 steps.  It turns out that with just 3 steps, there are 12 different possible arrangements!  I drew out all possible arrangements and determined a way to detect each of them.  After resolving the logic of rearraging 3 steps, I moved on to 4 steps.  My notebook is filled with sketches of all the different configurations and notes on how the arrangement should be saved in the database (see images above).

Finally, I added this nice little feature that animates the step when you rearrange them so you see exactly how the steps get moved.  It's surprisingly helpful to have this feature in place!  I still have a ton of debugging left to do, but you can see a video of the current interface above.  

Also, as a side note, I found it really useful to draw out different bugs on post-its and stacking them when I'm done.  That way, I can easily refer to different configurations later (rather than flip through pages in my notebook).

July 10, 2014 at 1:57 PM
Comments (0)

I just had my PhD quals this week and had a great conversation with one of my committee members, who gave me really awesome advice about designing BiP.  In particular, she had a suggestion about looking at extreme versions of BiP project pages, including a view that would only have images, and one that would only have text.

I had already been thinking about different viewing modes for a Build in Progress page and decided to try out a photo viewing mode.

You can now actually "secretly" view it by going to your project page and adding "imageView" to the URL.  For example, you can see an example here:

http://buildinprogress.media.mit.edu/projects/1631/imageView

Some things to check out:

  1. When you hover over an image, it highlights all other images from the same step and shows information about the step on the right-hand side
  2. Projects that have labels enable filtering - click on a step label on the left and see all images that fall underneath this label
  3. If you want to return to the regular BiP project page to see all comments, etc., you can click on the step name to open it up in the traditional view.

I've only just prototyped this, so not all functionality is there (for example, you can't view images in this videos yet), but I'd love to hear your thoughts if you have any. (:

December 5, 2014 at 11:37 PM
Comments (2)
Nice! I can see this as an awesome way to get people's attention!

Also I think you meant to say (for example, you can't view videos in this view yet)

Looking good so far!
over 2 years ago
Thanks! (: I fixed the mistake you pointed out too!
over 2 years ago