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