Dashboard UI mockup

[mbjones]

Design a UI mockup/ wireframe that quickly lays out the desired web functionality as listed in the use cases.

[matthewturk]

@ian-taylor I'm going to assign this to you, because you've been doing Dashboard work. Do you have access to create repositories? If so, when you develop a draft of an actual UI (as opposed to a mockup) it should go into one there.

[matthewturk]

@ian-taylor , @mbjones suggested we try out InVision: https://www.invisionapp.com/ . This seems like an outstanding way to iterate, particularly since we need to settle on a design before we move forward on implementation or tying together services. My username there seems to be tied to my gmail account.

[ian-taylor]

I checked in a dashboard in github. To install, do the following (as long as you have installed the latest version of npm and bower):

git clone https://github.com/whole-tale/dashboard npm install bower install and then: ember s to run the server and browse to

http://localhost:4200

to see the dashboard. The philosophy of the dashboard is centered around the discussions we have been having about how people will work with WholeTale e.g. they will add data, create a directory (drive) containing the data and code (including notebooks) they need to run an experiment, and then choose a frontend (e.g. jupytper) and a Docker container to provide the runtime environment for pulling everything together. So, out of this there are three things a user might want to do when logging in:

• search for data
• work with data (upload, create drives)
• publish research experiments.

For working with data, we have discussed two GUIs: a Web-based upload mechanism and OwnCloud. By following this route on the GUI, gets you to these place marks for integration. Search implenents a search (just place holder for now) and publish allows you to create the triplet defined above: dockerfile, drive + frontend. A progress bar provides an indicator of how complete the research experiment is and when complete, it gets to 100% and shows the selections. This combination is ready to be stored.

The implementation contains ideas from the use case but focuses on recent discussions to further them. We can integrate more of the use cases as we move forward.

This dashboard keeps the abstraction at the "drive" level, as discussed last Friday. This simplifies things a lot and I hope that these ideas are helpful in furthering these discussions. The data workspace and the frontend widgets rotate to allow you to browse all choices, which is a cool feature I think.

As for implementation, this is done using EmberJS and Semantic UI. The implementation is sound. It makes use of Ember components, which are really neat - they allow the creation of simple pluggable html components that can pass data back and forth, so that dashboards and wizard can be created by simply pulling in the various components, customized for the data you wish them to render. All GUI elements on the implementation are EmberJS components and the app has data models that are ready to hook up to a REST API to make this fully functional. Models in EmberJS resemble typical MVC frameworks but in EmberJS, the models update REST interfaces whereas an MVC framework updates a database, typically.

[matthewturk]

Test deployment here:

https://s1s80k-wtdashboard.test.nationaldataservice.org/

[nigaffney]

Overall a good look but some nits to pick

1> Two search boxes...confusing. How about the data search we call discover 2> We should align the colors and columns of Files, Drives and Research with their actions of Search (now Discover) Workspace, and Publish.
3> Should it be Discover/Contribute...Im looking for the where do I put my data? 4> Whole Tale needs to be a bit larger to fill that black bar. Right now its the third largest text on the page 5> Files should have an entry in the menu div from the menu button 6> On the about page, we really should put a vision statement about end to end reproducible and sharable research and the benefits to both researcher and the research environment.
7> I also hate to say it but we are going to need social media marketing (not it). And those should also go on the Contact Us page 8> Is there any way we can make that orange a bit more burnt? You would thing I was from that other UT.

We should also put on this some sort of box where users can see their own usage metrics on the dashboard. How many datasets and workflows are being used by others. How many of my things are public. And how many references do we see to my research. So maybe that can go in the first column above the instructional boxen. I do think some simple gamification of this can help us promote better utilization of what we see WholeTale being.

[ian-taylor]

Thanks, great points. The purpose of mocking an early (0.01 alpha) prototype up was to generate discussion, so glad it is working :)

I think we first need to define terms we want to use. I am still confused about what to call things e.g. search/discover, what should be on the dashboard, what are the workflows and what they are called, etc . Perhaps we can discuss these on the call tomorrow? That would be a good starting point.

I spent about 10 mins (copying and pasting from website) on the contact and about pages so certainly they need some word smithing and thought.

I can address some of the other points before the meeting tomorrow.

[nigaffney]

Absolutely. This is why having something to start the conversations is so important. This really helped me clarify how this will all work together. Good food for thought for the meetings today and tomorrow.

[ian-taylor]

Not on the invite for today's but looking forward to discussing tomorrow!

[mbjones]

Initial mockup completed a while back, and several iterations were implemented. Closing this ticket. If new issues come up that need mockups, let's open new tickets for it.