Re: [Mvpmc-devel] welcome

[Eric L. <er...@vi...>]

Okay, let's try that again.  Sorry for sending this twice Jim,
but I only sent it to you, and I meant to send it to everyone...

I like this statement the best of what I have seen here.  I have
no objection to implementing as much or as little of the MythTV
(or name your favorite PVR) frontend functionality  as anyone wants,
but, in the end, it needs to pass the Aunt Tillie test.  It needs to
be simple and intuitive to use.  If we run out of buttons on the
remote before we run out of MythTV features to exploit, so be it.

I think it would be best not to start with the MythTV user interface
as the thing we want to implement, since I don't think it passes the
Aunt Tillie test at all.  Basically, the MythTV frontend is very
computer and computer user oriented.  There are tons of geek knobs
like priorities, and recording profiles and so forth, that, Aunt Tillie
will not be able to cope with.  We can use these to our advantage,
but we should not, necessarily, expose the user to them.  The other
thing is, MythTV comes up initially in a menu that asks "What do you
want to do?"  A piece of consumer electronics, presumably, already knows
what you want to do.  For example, my TV comes on playing TV on whatever
channel it was tuned to when I turned it off.  My VCR does roughly the
same thing.  I am not saying that we want the MVP to do exactly the same
thing, but what I am saying is that the fundamental state of the MVP
should match its purpose.

To illustrate (this is an illustration, not necessarily a proposal) I
could imagine that the fundamental state of the MVP would be to pick
a MythTV recorder (based on criteria that might include "what was the
user watching last," "what is recording now," or whatever) and play what
is being received by that recorder.  Another possibility would be
roughly the same, but with list of recordings displayed.  Other
possibilities should be considered.  The bottom line is getting to
a "what do you want to do?" style menu should be reserved for, say,
pressing the menu button.

I would recommend that we avoid overloading buttons on the remote and
that we avoid 'busy' or confusing screens (carefully allocate
real-estate to particular functions).  A little fascism early in a
project like this goes a long way toward getting a clean result
later.

                 Eric


 >
 > Simpler is definitely better, especially in consumer electronics
 > which is basically what we're trying to write.
 >