[mythtv-users] Mythtv .19 live watching

chris at cpr.homelinux.net chris at cpr.homelinux.net
Fri Jul 14 12:39:11 UTC 2006


On Thu, Jul 13, 2006 at 03:40:26PM -0400, Michael T. Dean wrote:
> Interesting how the guy preaching about how lazy the MythTV developers 
> are doesn't have time to fix any problems.  I guess you're just saying 
> your time is more valuable than Isaac's, et. al, and they should get 
> right on fixing this problem for you.

Design and coding are separate tasks, and I happen to believe that 
the time I take to point out design flaws and propose solutions is 
just as valuable as the time you take to write code, particularly 
if proper design now saves you from having to waste a year 
refactoring again.  Most successful software companies will tell 
you that coders are usually too close to the problem to see the 
right solution.  That's why they split the project into the "design 
team" and "implimentation team".  I've worked on both.  Now my 
employer pays me to advise the design teams (for a project that 
involves recording vast quantities of non-television video, no 
less).

I generally like MythTV and want to see it succeed and improve, and 
am helping in the best way I can right now.  If and when I have 
time to write code for MythTV you'll be the first to know.

In any case, when someone challenges your design, assigning them to 
the "implimentation team" to shut them up is not helpful.

> Not going to make a comment about the importance of 150MiB (installed 
> size of X and less than 10 minutes of a recording at 2000kbps or 
> 5min at 4000kbps or 2.5min at 6000kbps) to a backend.  Not going to comment on 
> the backend's not needing a monitor (or even needing to run an X 
> server).  Not going to comment on the fact that Qt3 makes installation 
> of X mandatory, anyway, and that Myth requires Qt3.

Not going to comment on the fact that the size of X11 is not the 
origin of my complaint.  Not going to comment on the fact that the 
backend could have avoided using QT3 and dragging a lot of 
dependencies into the mix which only serve to make upgrades 
painfully complicated and sometimes impossible.  Not going to 
comment on the fact that you're either missing or avoiding my 
point, which is that a daemon which produces no visible output 
shouldn't be ham-strung by a GUI-only installer.  GUI installers 
are usually implimented as optional front-ends to a text-based 
installer for a reason.

> I have.  And, while I generally respect ESR's opinions, I feel that 
> essay is just plain wrong.  He talks about the usability of CUPS based 
> on the GUI configuration tools provided by Fedora Core (not by CUPS).

A point which he addressed in his follow-up article a month later.  
He wasn't blaming the CUPS team for a bad product, but showing how 
a bad design (GUI or otherwise) can drag a product down.  In that 
specific case it may have been a RedHat add-on that caused the 
problem, but assigning blame or disputing details at the expense of 
ignoring the big picture is a waste of time.  Even the CUPS team 
generally agreed with his observations.

> Encoding additional meaning into priority?  Yeah.  That's intuitive.  
>  From ESR's essay that you quoted, "Rule 1 of writing software for 
> nontechnical users is this: if they have to read documentation to use it 
> you designed it wrong."

The trick is to hide the technical bits from the user so that the 
priority levels and their effects can be observed without requiring 
training.  A "discoverable" interface might simply insert breaks in 
the priority listing that say something like "shows below this line 
will be deleted if required", etc.  The actual values and their 
meanings don't have to be hard coded or even shown.  A user could 
change the priority of a show up or down so that it not only 
reflected their relative values but was also contained in the 
section of the list that meets their needs.  Given that you already 
have so many variables involved in the prioritization process, 
hiding the details from Aunt Tillie will be rather hard, though.  
She's already unable to use Myth without training.

Of course there are solutions.  If I thought I'd get a reply other 
than "I don't care" I'd propose some.



More information about the mythtv-users mailing list