Hi Michelle,
I think the types of info for the capture agent needed would basically
be a condensed version of what is on the Reference Hardware page:
http://opencast.jira.com/wiki/display/MHDOC/Reference+Hardware+V1.2
so it is probably too much info to simply tack on to the MH adopters
pages. However, it would be useful to create a link from the adopters
page to the capture agent pages used by each institution (though I am
not sure how easy that might be!).
As for the content of the capture agent page, I see:
1. What type/usage of agent (i.e., screencast only, SD video +
screencast, HD video + screencast)? Total number of this agent in use.
2. Hardware spec (basically something along the lines of the table for
the Reference Hardware page)
3. MH (or other) Config special to this setup
4. Notes (i.e., we have tested running this agent at xxx bitrate and
this uses xxx CPU power)
5. [probably not all feasible to include at the start] Links/info on the
institution and maybe other capture agent/server setup info
I think the above info would be a good start for a capture agent info
template.
Kevin Chan
Operations Team
Educational Technology Services
UC Berkeley
On 2/10/12 6:30 AM, Michelle Ziegmann wrote:
So we have this page: http://opencast.org/matterhorn-adopters, where
adopters identify themselves as such to the community and provide some
details about their implementation. It serves a good marketing
purpose, but the Matterhorn Deployment details could be expanded to
meet the need you're discussing here as well.
I'm preparing to make a call to those adopters on this list to update
their entries, and to the community for other adopters to add
themselves. If you all think this format could be useful for capturing
and providing those implementation details, I can first modify this
form to enable it to collect more information. What do you think? If
you like the idea, what fields/options would you suggest we add?
Or is the information you're seeking too detailed to put here?
Michelle
On 2/9/2012 4:18 PM, Kevin Chan wrote:
Hi all,
I think what Nils is proposing makes sense. Aside from
separating/searching by "capture agent types" (screencast only, SD
video + screencast, HD video + screencast, etc.), it is also useful
to sort by (or provide a list of) institutions' capture agent setup.
For example, at UC Berkeley, we are likely going to have 3 different
types of capture agents - screencast only, SD video + screencast, HD
video + screencast - we would also provide additional "institutional"
info on why we have these setups, contact info, links to real life MH
distributions.
Admittedly, this approach works better for system wide applications
(we are a large school with this many concurrent/peak users - here is
our hardware setup), but I think having this view into how MH is
actually being implemented would be useful.
Finally, we might even piggy back other MH setup info (like
admin/worker/engage setup, storage setup, distribution channels) that
would prove useful to other potential adopters.
Kevin Chan
Operations Team
Educational Technology Services
UC Berkeley
On 2/8/12 10:22 AM, Nils Hendrik Birnbaum wrote:
Hey Folks,
as I'm working a lot with our documentation I found pages the were
at the first glance outdated. Today when I came home from office
reading some of the mails around the CA dropped frames - hardware -
whatever issues I got the opinion that outdated is the wrong
description - we wrote them from the wrong point of view and we use
terms we all know well but everybody has his own understanding what
he means. It's one of the major problems in requirements engineering
(RE). To illustrate it, please look at [1] (german server, english
texts). (This cartoon is an important element in most of the RE
certifications)
I would like to keep the example of the CA. And we should ask
ourselves, what are the information the adopter has in his mind when
he goes to the reference hardware page and what are the pitfalls we
run into day by day.
In general he would say "I want to record lectures". In his mind he
got more specific ideas how this recording will join on and what the
result of the recording is. This thought will be affected for
example by an existing system that should be replaced, recordings he
saw in the wild on youtube or iTunes that could be recorded with
Matterhorn or any other system and so on.
Same with our day by day work. We talk about
*"successful recordings" (Framerate, resolution, size, devices, ...)
* Purchasable hardware (in North America, Europe, everywhere, ...)
So the language bites us (free translated by myself). We should talk
more precise, using a glossary ..
And my approach would be to create the landing page for our
different modules which bases on the adopters requirements. The
first thing that came into my mind is the quality of the video. That
determines the hardware specs so they can be grouped by 3 or 4
target qualities and the adopter can watch examples and decide which
hardware he needs.
This is an easy approach to safe time for answering questions on the
users list caused by different meaning.
Just my two cents and a small example, please give me some feedback
for kind of an e-mail brainstorming (I will nor answer this week to
stay away from a discussion, we could to this later on)
Regards
Nils
[1] http://interface-gmbh.de/Anforderungen_WAS_aus_Pj_wurde.JPG
_______________________________________________
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]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
