tributary v1 redesign

[Ian Johnson]

Hi folks,

So we've been working towards a v1 of tributary, and Sarah contributed these mocks for how we might clean up the UI.

We are still iterating on them to include a big new feature around managing data, but I thought I'd share what she did to get the discussion going :)

--
Ian Johnson - 周彦

http://enja.org

[Geoffery Miller]

I don't have any criticism besides the fact that this looks awesome.  Love it.

I like the use of the top right for config, fullscreen and screenshot(gif?) button.

[Drew Skau]

Really minor issue, but the drop shadow here seems unresolved to me:

It would also be good to see what happens to the same region when a different tab is active.

Overall, looks amazing! Proud to know you guys :)

--
You received this message because you are subscribed to the Google Groups "Tributary" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tributary+...@googlegroups.com.
Visit this group at http://groups.google.com/group/tributary.
For more options, visit https://groups.google.com/groups/opt_out.

[Ian Johnson]

thanks drew :D

[theta theta]

Looks promising! ..and inviting! 

From a usability point of view, the thing I miss most from the early version of Tributary is the ability to arbitrarily resize the scripting window.

Shine on people! wow!

[Geoffery Miller]

I have a few questions about this interface all relating the behavior of the user's github account, some of which stems from the fact that many times someone will be looking at someone else's work, but also have their own account or be anonymous.

A) If I am not logged in:

1) How can I log in?  

2) If I am looking at someone else's inlet, will Fork automatically ask me to login?  

3) If I am looking at a fresh blank inlet, will save ask me to login?

B) If I am logged in:

1) If I am looking at someone else's inlet, is there a point for "Save" to show?  Just fork?

2) If I edit someone else's inlet, could I be presented with a "Save and Fork?" Then people might not be confused what will happen if I fork --  some assurance that I will get my changes saved in the fork. (Also if someone doesn't know what forking is, well at least that person gets that it will be saved somehow)

3) How will I know that I am logged in? 

4) How can I log out?

A side question: what does the down arrow next to the user picture imply that I could do with it?

[Ian Johnson]

These are great questions. they answers aren't fully resolved, I wonder if EJ and Sarah have ideas.

I know that what we've been doing is showing "Save" all the time, and only showing "Fork" if you are logged in and looking at your own thing. This is to reduce friction for people that don't know what Fork means, but I'm becoming more of the mind that we should say Fork whenever its forking behavior and people will just have to learn. In the last hangout we resonated on the idea that tributary is a tool for us to build and teach with, and we should make it awesome and make sense for us.

Also, you can save or fork anonymously so it wont have to prompt you to login, tho it should be obvious that you can.

One of the things we mentioned in previous hangouts was making this history of the inlet more prominent. Sarah wasn't aware of that goal when she did this, so we need to work that in. I believe we can come up with a solid way to show history which will alleviate concerns around looking at someone elses. As for your own login stuff I think EJ might have had a different take in his mock, which he's supposed to share here :P

those are good questions tho, and we should definitely be able to answer all of them specifically as part of the v1 release!

--

You received this message because you are subscribed to the Google Groups "Tributary" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tributary+...@googlegroups.com.
Visit this group at http://groups.google.com/group/tributary.
For more options, visit https://groups.google.com/groups/opt_out.

[Jeff Friesen]

Some thoughts the design and redesign from a new Tributary user (and relatively new d3.js user):

There are some magical things going on here that aren't obvious unless you know them from watching the screencasts (which are helpful). For example:

1. Accessing an external data file within the main inlet.js window: 

var data = tributary.datafile; 

After knowing this and reading the wiki, it kind of makes sense, but still kind of obscure for such an important function. Maybe there is a note at the top of the datafile.csv that tells you how to access it in the main script?

2. Accessing the #display element:

Similar to the last one - if you already know it this is obvious. You can use the inspector to find it, however, there is a lot of stuff going on in the inspector. Why not #container? How do I really even know to look in the iFrame? What's the best practice? Making that clear somehow would help.

3. Display type:

The question mark explanation doesn't open anything for me. I still don't really know the difference is between the svg/canvas/webgl/html options. If I choose HTML, does that mean I can't insert SVG (or vice versa)? I ran into this confusion when trying to use dc.js in tributary. I couldn't figure out how to include different charts on the screen. 

I think addressing these problems will make it much more accessible to new users. Even though some of this may be solved with documentation, the more obvious it is in the UI the better. But I know it's a challenge.

Watching the screencasts and the little bit of playing with Tributary I'm psyched. It's pretty awesome. Good job.

[Geoffery Miller]

Jeff, very valid points.  I remember when I was starting to learn d3.js with tributary and really had no idea what the display types were doing, how to access data files, or what the 'hello world' code was.  I ended up learning from other inlets, which I think might be what we want people do to anyway.  But it would certainly be possible to explain this better with the UI, or even just provide prominent links to very simple boilerplate code to fork from.

Geo

--
You received this message because you are subscribed to a topic in the Google Groups "Tributary" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tributary/7YEKQ4BLVAY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tributary+...@googlegroups.com.

[EJ Fox]

Hey all,

I took Sarah's ideas and ran with them, filtering them through some of the ideas that Ian and I have been discussing for a new version of Tributary. 

You can see my version here: http://f.cl.ly/items/0A0p203Y3e1U403i1u2O/Tributaryv1.pdf

The most important addition that I am looking forward to is a vertical toolbar to the left of the code/data panel. I am thinking of this similar to to the way Chrome treats the space to the right of the URL bar, as a user installs/includes new Tributary plugins, or we add new features, they would appear as icons in that vertical bar, and when clicked, would have their own panel area to have their own GUI. I've mocked up a couple of panels, but only 1 should be shown at a time. 

I think this will help modularize things a bit more as we continue to expand Tribtuary's functionality. We've kind of painted ourselves into a corner with the current UI, with the buttons at the bottom of the code panel, and the GIF button at the bottom of the display. Also it's just weird to me. This new vertical toolbar will allow space for more functionality added by both us and hopefully 3rd-party plugins. 

We have also been talking about better supporting the process of bringing data into Tributary to visualize this. This is going to be an entirely new panel which will replace the code panel and allow you to both include data files (csv, json), paste raw data, or add API calls that are expected to return JSON. The data panel will handle manual refreshing of the data sources so you don't make an API call every time you type. Depending on the size/content of the data returned, the panel will show the data as a SlickGrid https://github.com/mleibman/SlickGrid use https://github.com/padolsey/prettyprint.js to show JSON or just fill a <pre> with properly indented raw JSON if the data is large. 

With a better handle on data importing, I think we should move away from dealing with individual files. I think this is an IDE-like function, and we are not looking to replicate an IDE. We are trying to make D3/Dataviz prototyping and sketching as quick, fun, and painless as possible. With no more files, the tabs above the code panel will become Script, HTML, Style, and Data. Script/Style/HTML would work the way that tabs currently work, simply changing the contents of text editor, but the data tab would completely replace the code panel as shown in the mockup. 

From a usability point of view, the thing I miss most from the early version of Tributary is the ability to arbitrarily resize the scripting window.

Resizing the code window is a developer-pain/user-benefit tradeoff I haven't been convinced of yet. I don't like it because then we are using JS to control the layout and that is weird and unpleasant. For the new design I am planning on using flexbox https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes which should actually make it easier to resize the different parts of the UI on the fly without everything breaking. 

Would it be an alright compromise to be able to say, hold the alt button, and when you do your mouse cursor turns to a horizontal resize icon when on the left edge of the code panel, and you could resize it on the fly. The resize would change back to the default whenever the page was refreshed. Or would that defeat the point in your eyes? 

A) If I am not logged in:
1) How can I log in?  
2) If I am looking at someone else's inlet, will Fork automatically ask me to login?  
3) If I am looking at a fresh blank inlet, will save ask me to login?

I can answer Geoff's questions on the thinking for my own mockup, I can't speak for Sarah. 

1) Logging in will be the only text that appears above the code panel, where it currently says "Logged in as...", when logged out that would show "Log in" 

2) I am not totally sold on whether users who are not logged in will even see the Fork button. It is kind of an advanced concept, and not a necessary one to understand to get started. 

3) I would say yes. Popping up a modal that asks the user whether they'd like to save it anonymously, log in, or sign up would be beneficial I think.

B) If I am logged in:
1) If I am looking at someone else's inlet, is there a point for "Save" to show?  Just fork?
2) If I edit someone else's inlet, could I be presented with a "Save and Fork?" Then people might not be confused what will happen if I fork --  some assurance that I will get my changes saved in the fork. (Also if someone doesn't know what forking is, well at least that person gets that it will be saved somehow)
3) How will I know that I am logged in? 
4) How can I log out?

1) I think you are right and there should probably only be a fork option

2) That sounds ideal. I think it would be helpful to think through all the situations  and figure out what happens. Something like this?

A logged out user editing a new blank tributary - "Save"

A logged out user editing another user's tributary - "Save and Fork"

A logged-in user editing a new blank tributary - "Save"

A logged-in user editing an existing tributary they've created - "Save" + "Fork"

A logged-in user editing an existing tributary by someone else - "Save and Fork" 

3) You should be looking for your name above the code panel

4) Log out will be right next to your name in the code panel when logged in

A side question: what does the down arrow next to the user picture imply that I could do with it?

I am imagining a dropdown that would give you link to that user's GitHub account and to their Tributary history page, would be awesome if you could get their Twitter handle so you could @reply tweet them with a link to their Tributary from the UI, if you had a question or feedback. 

1. Accessing an external data file within the main inlet.js window: 
var data = tributary.datafile; 
After knowing this and reading the wiki, it kind of makes sense, but still kind of obscure for such an important function. Maybe there is a note at the top of the datafile.csv that tells you how to access it in the main script?

This is great feedback. I am hoping that the UI panel will make this a bit easier. For example once a datasource has been added, a variable like you mentioned could be prepended commented out in the scripts file. I think you are right that the data panel should have some dedicated UI/tooltips that tells you how to bring the data into your script file. 

2. Accessing the #display element:
Similar to the last one - if you already know it this is obvious. You can use the inspector to find it, however, there is a lot of stuff going on in the inspector. Why not #container? How do I really even know to look in the iFrame? What's the best practice? Making that clear somehow would help.

Talking to Ian, I think it is possible to make the entire contents of the iframe show up in the HTML tab mentioned above. This should make this stuff a lot clearer, so you don't have to inspect within the iframe to find out what's going on with the non-script parts. This should also make things more bl.ocks.org like, in that you could just copy the files you are working with locally in and then play with Tributary, rather than using Tributary-specific IDs/variables exclusively. Do you think that would help?

The question mark explanation doesn't open anything for me. I still don't really know the difference is between the svg/canvas/webgl/html options. If I choose HTML, does that mean I can't insert SVG (or vice versa)? I ran into this confusion when trying to use dc.js in tributary. I couldn't figure out how to include different charts on the screen. 

The HTML tab should help with this. When you change the display time, currently Tributary provides you with the right DOM element and a variable to access it, and inserts the HTML into the iframe. It should be that when you are in the HTML, you could switch the display type in Tributary and it would automatically modify your HTML to give you SVG or Canvas if that is the display type you want, but you will see the code change right in front of you which should make things clearer. Choosing HTML should mean that we don't automatically provide you with an SVG element, NOT that SVG shouldn't be used at all. 

This is probably the weirdest part of the UI/Tributary and will require the most thinking. Either Tributary handles it automatically, or we leave it in the hands of the users doing it themselves in the HTML tab. 

--EJ Fox
ej...@ejfox.com
twitter.com/pseudoplacebo

--

You received this message because you are subscribed to the Google Groups "Tributary" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tributary+...@googlegroups.com.

[Jeff Friesen]

Mockups are looking good.

1. Accessing an external data file within the main inlet.js window: 
var data = tributary.datafile; 
After knowing this and reading the wiki, it kind of makes sense, but still kind of obscure for such an important function. Maybe there is a note at the top of the datafile.csv that tells you how to access it in the main script?

This is great feedback. I am hoping that the UI panel will make this a bit easier. For example once a datasource has been added, a variable like you mentioned could be prepended commented out in the scripts file. I think you are right that the data panel should have some dedicated UI/tooltips that tells you how to bring the data into your script file. 

a prepended, commented out line of code referencing the scripts is a great solution

2. Accessing the #display element:
Similar to the last one - if you already know it this is obvious. You can use the inspector to find it, however, there is a lot of stuff going on in the inspector. Why not #container? How do I really even know to look in the iFrame? What's the best practice? Making that clear somehow would help.

Talking to Ian, I think it is possible to make the entire contents of the iframe show up in the HTML tab mentioned above. This should make this stuff a lot clearer, so you don't have to inspect within the iframe to find out what's going on with the non-script parts. This should also make things more bl.ocks.org like, in that you could just copy the files you are working with locally in and then play with Tributary, rather than using Tributary-specific IDs/variables exclusively. Do you think that would help?

I think this would help. Having access to the HTML would also be a great learning tool as well. For example, it can be confusing when learning d3 what happens when you select all of these elements on the page that don't exist yet. But then they magically get added when you join the data. Being able to see what happens in the HTML on enter and exit is really interesting. 

What if you could toggle views on the left pane between display (rendered) and html? So on keyup of JS, you can either see charts appearing or HTML being appended/removed? Knowing what's happening in the HTML is critical to understanding and building D3 visualizations.

The question mark explanation doesn't open anything for me. I still don't really know the difference is between the svg/canvas/webgl/html options. If I choose HTML, does that mean I can't insert SVG (or vice versa)? I ran into this confusion when trying to use dc.js in tributary. I couldn't figure out how to include different charts on the screen. 

The HTML tab should help with this. When you change the display time, currently Tributary provides you with the right DOM element and a variable to access it, and inserts the HTML into the iframe. It should be that when you are in the HTML, you could switch the display type in Tributary and it would automatically modify your HTML to give you SVG or Canvas if that is the display type you want, but you will see the code change right in front of you which should make things clearer. Choosing HTML should mean that we don't automatically provide you with an SVG element, NOT that SVG shouldn't be used at all. 

That makes sense. The HTML tab could start out with just this:

<section id="display">

<svg xmlns="http://www.w3.org/2000/svg" xlink:xlink="http://www.w3.org/1999/xlink" class="tributary_svg">

</svg>

</section>

Or this for the HTML:

<section id="display">

</section>

[theta theta]

Would it be an alright compromise to be able to say, hold the alt button, and when you do your mouse cursor turns to a horizontal resize icon when on the left edge of the code panel, and you could resize it on the fly.

completely, that would be fine.

[Luc Rocher]

Hi all,

I just tried tributary and was ready to propose myself for a “redesign”, just before checking the google group. Are you looking for help/reviews in the process?

Did any of you started to code a working prototype since last year?

Best,

Luc

[Ian Johnson]

Hi Luc,

We'd love any help we can get. I have started coding in the v1 branch, but its semi functional right now.

Id love to hear/see your ideas and what you had in mind for a redesign. Lately Ive had some new ideas for simplifying things so that i actually make some progress. i still need to share those. (im traveling for the month if feb, so lots of time to think but not much to code)

Ian

--

[Luc Rocher]

Hi Ian,

I think tributary lacks of consistency, especially in the header. The focus should be more on code and visualisation.

The login/save/fork… part needs to be simplified. Why not:

1. display only the author+inlet name at the opening;

2. display your name + empty inlet name when you start editing the document.

Simple mockup attached.

Luc

[Ian Johnson]

I agree that simple is better, but how would someone fork an inlet?

one of the best uses of tributary is a back-and-forth exchange between two people by forking the same code.

are you saying the save options only show up once you've edited? that does make sense to me.