Hi Judy, thanks for the changes to the mockups. I welcome the ideas that you brought forward and we'll do our best to get the implementation as close as possible.
There is one more comment on the mockups that I would like to make. I don't think that the label on the "In process" tab is appropriate. The user should be able to see "finished" and "failed" recordings as well, and as soon as we add these two filters back, "In Process" does not fit anymore. Any thoughts? Tobias On 16.09.2011, at 03:17, Judy Stern wrote: > Thanks for bringing this back to the immediate reality of our next release, > Tobias. We do, however, want to make sure that our "small steps" don't make > the Matterhorn Admin UI inconsistent and confusing. > > Here's what I propose for the short term: > http://opencast.jira.com/wiki/display/MH/Keeping+Episodes+UI+Separate+from+Workflow+Instances+UI > > My goals: a) ensure that the introduction of the episodes UI doesn't also > introduce inconsistencies in the UI and b) put everything that folks think of > as "recordings" (workflow instance and episodes) under one tab as a first > step to merging them, while c) introducing as few changes as possible to the > existing recordings UI, and d) not requesting functionality in the episodes > service beyond what has been proposed by Tobias & Christoph. > > What I did in the design : > 1) Included the Episode UI under the Recordings tab, making it an alternative > view to our current table of workflow instances. This way the two different > views of Recordings aren't completely separated. > 2) Called the two different views "In Process" and "Archived". ("In Process" > is pretty close to your original proposal of "Processing" without re-using a > term already used in the UI to mean something else. And the term "Archived" > comes up frequently when you guys describe the episode service.) > 3) In the episodes UI, changed the mechanism and labeling for selecting a > workflow to be a bit simpler and more standard, as well as avoiding the term > "workflow" (which I'm considering re-considering ;-) ) > 4) In the episodes UI, removed the Process column ( since the episode service > "is _not_ for tracking their processing") and removed the Actions column > since Christoph said he was going to do that anyway. > 5) In the episodes UI, added a Series column (for completeness and > searchability) > 6) Made a few other small changes in the Episodes UI design so that we'd have > a little more consistency in the UI: a) moved the search box to the right > (also a more standard place to put it), b) changed the select column to match > that of our existing bulk action UI. > 7) Change the "All, upcoming, processing, etc" filters to links because > otherwise we'd have too many green button-looking things at the top of the > page. (They were originally links and UI developers changed them at some > point. Even without "In Process" and "Archived", it's just too many dark > green rectangles competing for attention and I was going to suggest we change > it back to links for 1.3.) > > New Issues/questions raised: > 1a) If we continue to show Finished & Failed with the other workflow > instances, we need to do something to differentiate workflow instances run on > the same mediapackage. How hard would it be to add a column to the workflow > instances table (current "Recordings" UI) with processing date/time & the > name of the workflow selected? Who is available to do this work? > 1b) What about not showing Finished in the current Recordings UI? No > information is provided for Finished Recordings that wouldn't also be in > "Archived", other than confirmation that they actually did finish > successfully. How hard would it be to no longer show "finished" items with > the other workflow instances (as we do in current recordings UI) and instead > show something in the episodes UI to indicate that a workflow on that > mediapackage finished successfully? And, "Failed" recordings, too? What do > we lose? > 1c) I don't love "Archived" as the way to describe the episodes UI. (But I > think it's better than "Episodes".) If we stop showing "Finished" recordings > under "In Process", we could potentially call the episodes UI "Finished". > Other ideas? (I liked "idle" that Ruben came up with, even though he didn't > like it himself, until I realized that folks probably think of "on hold" as a > form of "idle"...) "Processed"? > > Still outstanding: > 1) Questions about setting options for workflows (Christoph: "Good point. We > need to think about this.") > 2) Questions about how to prevent the running of simultaneous workflows on > the same recording when it can cause errors (Christoph: "responsibility of > the workflow service...ask Tobias/Josh...") > > I've got many more thoughts running around my head, but I'll stop here. > Feedback welcome! > > Judy > > > On Sep 14, 2011, at 3:26 PM, Tobias Wunden wrote: > >> Hi Judy, >> >> On 14.09.2011, at 20:59, Judy Stern wrote: >> >>> As I reread this, it's all getting clearer. In particular, there's an >>> important notion in this statement: "Not saying that a tab showing all the >>> workflow instances is not useful anymore, but I believe that being able to >>> see the workflows applied to each episode is better." Leads to one big >>> question at the moment: What are the needs (use cases, user stories, etc.) >>> that require a sortable view of all workflow instances? If we have an >>> Episodes UI, why not call it "Recordings" (replacing what's in Recordings >>> now)? If we could add the display of a bit more data (e.g. "Recording >>> Date/Time") to the UI Christoph is proposing and provide a way to filter >>> the episodes by status (e.g. to only those actively running a workflow, >>> with further filtering based on which phase it's in), we'd have close to >>> all of the information in the current Recordings UI. What am I missing? >>> More importantly, what would users be missing if they don't have a table of >>> all workflow instances? (I guess part of the answer is dependent on whether >>> we need to simultaneous workflows running on the same episode…) >> >> In my mind, you are describing above the final design of the episode >> service, this is what it should be in the end. However, we should be able to >> take small steps, especially given that this work is sponsored and should, >> if possible, make it into 1.3. >> >> Adding a separate episode ui is the proposed first step, merging it with >> workflow the logical second one. >> >> Tobias >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ > > Judy Stern > Educational Technology Services, UC Berkeley > [email protected] > > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
