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] _______________________________________________
