Re: Yanoff questions and comments

"Danita Zanre" <[email protected]> wrote in message
news:[email protected]...
>
> I work in support, and I sometimes feel like a "professional" beta tester!

It is always useful when people are disappointed AND let me know AND are
specific (including detail the "better way to do it").  These responses
always get consideration and many of them get implemented.

> I don't really expect Yanoff to be a desktop replacement,

This is a good thing to keep in mind, because it was not, is not, never will
be and was never intended to be OE on Palm.  PDAs have very specific
characteristics that drasticly constrain and influence design options.

> So I don't ever feel like I'm trying to be "unreasonable" when I bring up
ideas

Be unreasonable; that's fine: Just be SPECIFIC (as you are).

> > It is very uncommon that marking un/read is actually useful in itself;
it is
> > generally done as a preparation for some kind of deletion operation...
>
> Well it is for me <g>....

Everything you described is available in the app you have, but most of it is
confined to ButtonAction Prefs, due to limited menu item space.  I am sure
you've discovered this by now...

> 1. The newgroup list shows how many messages are in each group,
> but doesn't indicate if there are any "new" messages.

Here is a PERFECT example of a Palm-limitiations design decision.
The number of items in any PDB (such as NewsArts.pdb) is stored by the OS
and is maintained as an actual always-updated number.  So to get this
information is 1 system call which grabs 1 memory location and returns a
value.  However in order to know how many articles are unread, app-layer
work must be done.  I must either keep track of this information myself, or
generate it whenever required.  My Treo can examine about 30 articles/second
(older HW much fewer).  I carry several thousand articles at all times.  If
I were to calculate the number of unread articles in a group every time I
needed to display it, it would take interminable long.  On a PC, the
horsepower to do this is there, generating the count on the fly is trivial
due to incredible CPU power.  The only possible option is to maintain this
number ourselves.  This is not a simple as it seems.  First of all there is
the conduit.  This horribly complicates things.  The main problem is that
we've never even opened the conduit project and have no experience modifying
it (maybe sometime).  Even if we ignore that, there are HUGE problems with
NVFS and caching that frequently cause PDB information to not get saved when
it should.  This would surely cause the count we keep to get "off" at times.
Then we'd have to add an audit or manual option to validate theses numbers
and in the end, there'd be so much code and UI baggage, it just doesn't seem
worth the small benefit.  I do have one way to exploint an OS function that
might make this practical on Palm (using categories which are also
maintained by the OS "for free") but this would be a very significant
redesign and cause several other problems.  When it is examined in this
light, with the other list of things that might be done, the feature just
keeps moving down the list...

> 2. Relative to #1, I have a BA in the message list to
> go to the "next newsgroup 1st unread message"
> it would be nice if this could skip to the
> "next newsgroup containing unread messages"

Yes, whenever the basic "unread message" problem is solved, many new BAs
will be possible...

> 3. It would be nice if "locked" messages could behave as "unread" messages
when  you enter a group

In what sense?  Any operation you can do on the "read" flag, you can do on
the "locked" flag...
I am dense: spell out exactly how it would work...

> I realize that I could "mark" messages and then "unread all marked" and
"lock all unread" before a move to a new group so that next time the
messages I'm "working" on are still "unread" and "locked" - but that's
getting complicated!

So you want to short the lock flag to the read flag.  Whatever changes one
(or perhaps what ever changes the read flag) changes both.
This would be a VERY easy feature to implement.  Perhaps the following Misc
Prefs (or would it be NG/Server option for more flexibility):
Pin Lock Flag to Read Flag
Pin Read Flag to Lock Flag
Conjoin Lock and Read flags

> Maybe someday we'll be able to chain actions to a button!

Even though it looks fairly "cookie-cutter", it is not coded that way.
Because "walking" through the article list is so slow, we code the work into
every loop operation for maximum speed.  Stacking BAs would cause multiple
walks through the article list and just wouldn't be practicle.  There's most
likely some design trick that would make a happy medium but I haven't run
across it yet...


> Thanks!  And again - it's a great program!  I'm happy to have it now!

Even though I can justify the many design compromises that make things less
than intuitive, I know things could and should be better.  The main goal I
have had so far is adding FUNCTIONALITY and reworking things as I can
squeeze it in.  I've made the decision that it is better to have maximum
functionality even if the cost is some user dissatisfaction.  There is
always going to be a learning curve with powerful tools.  I'd really like to
go back and rework some things (and probably will) but as it is, I have not
even been able to finish the really BIG important features that the app very
much needs.  We must all prioritize....





To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/yanoff/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/yanoff/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/