|
I don't have any real ideas about how to better identify decoders. I agree it's a mess, and will be happy to implement whatever you guys think is best.
Mark Gurries made a suggestion a while back that I think would help with the user interface. He suggested that, instead of a single long list of decoders that's ordered by manufacturer, that we split it into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the left, that will restrict the other two to just that manufacturers families and models. If we auto-identify the manufacturer, that also does the restriction, so people just see the ones from that manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx, or "FX Decoders" for Digitrax. The idea is to have them be "so close together that they basically all program the same". Even if you're not sure of the particular model, and the program can't figure it out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for that in the "Model" column. If they don't see it, perhaps because nobodies ever made a file for it, but know that it's from "Wizzo Co", they could select that under manufacturer (or maybe decoder ID would do that), and look at the families. They they might realize that it's a "CoolChip" decoder, select that family, and be close enough to function.
Does this sound like it could help?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Bob,
I think I suggested a similar approach that was simpler. The dropdown
decoder list just shows manufacturers, but then there are flyout menus for
each manufacturer that list the models. If you like the family apprach,
you could flyout the family menu from the manufacturer instead, then have
the models flyout from the family. This advantage of this approach over
Mark's is that there is no need to enter data manually ahead of time for the
mfr or the family.
Robin
toggle quoted message
Show quoted text
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Friday, May 31, 2002 10:52 AM
To: jmriusers@...
Subject: [jmriusers] Change the way we present decoder names?
I don't have any real ideas about how to better identify decoders. I
agree it's a mess, and will be happy to implement whatever you guys
think is best.
Mark Gurries made a suggestion a while back that I think would help
with the user interface. He suggested that, instead of a single long
list of decoders that's ordered by manufacturer, that we split it
into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the
left, that will restrict the other two to just that manufacturers
families and models. If we auto-identify the manufacturer, that also
does the restriction, so people just see the ones from that
manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx,
or "FX Decoders" for Digitrax. The idea is to have them be "so close
together that they basically all program the same". Even if you're
not sure of the particular model, and the program can't figure it
out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including
the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for
that in the "Model" column. If they don't see it, perhaps because
nobodies ever made a file for it, but know that it's from "Wizzo
Co", they could select that under manufacturer (or maybe decoder ID
would do that), and look at the families. They they might realize
that it's a "CoolChip" decoder, select that family, and be close
enough to function.
Does this sound like it could help?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
I'm still getting my DCC system up and running; so, I'm not (yet) a
JMRI user; but, I work in the software development industry, so I'll
jump in and offer up my $0.02.
Perhaps what is needed is a simple search facility; so, if a specific
decoder is not listed, you could search for decoders that have similar
attributes (as listed on the mfg web site and/or the product
information supplied with the decoder). These attributes could
include (but not limited to)
* Manufacturer
* Power rating (1A, 1.5A, 2A, etc.)
* # functions
* FX
* Back EMF
* speed steps
* supported CV's
* etc.
Jon
|
'Family' seems like a rather confusing category. Dividing the list by
manufacturer is a good idea. In other words, I agree with Robin.
Mike
toggle quoted message
Show quoted text
On Friday 31 May 2002 11:06 am, Robin Becker wrote: Bob,
I think I suggested a similar approach that was simpler. The dropdown
decoder list just shows manufacturers, but then there are flyout menus for
each manufacturer that list the models. If you like the family apprach,
you could flyout the family menu from the manufacturer instead, then have
the models flyout from the family. This advantage of this approach over
Mark's is that there is no need to enter data manually ahead of time for the
mfr or the family.
Robin
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Friday, May 31, 2002 10:52 AM
To: jmriusers@...
Subject: [jmriusers] Change the way we present decoder names?
I don't have any real ideas about how to better identify decoders. I
agree it's a mess, and will be happy to implement whatever you guys
think is best.
Mark Gurries made a suggestion a while back that I think would help
with the user interface. He suggested that, instead of a single long
list of decoders that's ordered by manufacturer, that we split it
into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the
left, that will restrict the other two to just that manufacturers
families and models. If we auto-identify the manufacturer, that also
does the restriction, so people just see the ones from that
manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx,
or "FX Decoders" for Digitrax. The idea is to have them be "so close
together that they basically all program the same". Even if you're
not sure of the particular model, and the program can't figure it
out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including
the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for
that in the "Model" column. If they don't see it, perhaps because
nobodies ever made a file for it, but know that it's from "Wizzo
Co", they could select that under manufacturer (or maybe decoder ID
would do that), and look at the families. They they might realize
that it's a "CoolChip" decoder, select that family, and be close
enough to function.
Does this sound like it could help?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Bob,
What about by Manufacturer, Scale, Model
Example:
Digitrax, N, DN142
or
North Coast Engineering, HO, D13SR
Al Silverstein
toggle quoted message
Show quoted text
----- Original Message -----
From: Bob Jacobsen
To: jmriusers@...
Sent: Friday, May 31, 2002 1:52 PM
Subject: [jmriusers] Change the way we present decoder names?
I don't have any real ideas about how to better identify decoders. I
agree it's a mess, and will be happy to implement whatever you guys
think is best.
Mark Gurries made a suggestion a while back that I think would help
with the user interface. He suggested that, instead of a single long
list of decoders that's ordered by manufacturer, that we split it
into three selection boxes:
(Mfg) (Family) (Model)
When you pick a particular item in the "Manufacturer" box on the
left, that will restrict the other two to just that manufacturers
families and models. If we auto-identify the manufacturer, that also
does the restriction, so people just see the ones from that
manufacturer.
The "Family" one would then be things like "LC Steam" for Soundtraxx,
or "FX Decoders" for Digitrax. The idea is to have them be "so close
together that they basically all program the same". Even if you're
not sure of the particular model, and the program can't figure it
out, you'll probably not get in trouble.
And then the "Model" box would get down to the specifics, including
the number of output wires on a specific model, etc.
So if somebody knew that they had a "PQ197PJ", they could look for
that in the "Model" column. If they don't see it, perhaps because
nobodies ever made a file for it, but know that it's from "Wizzo
Co", they could select that under manufacturer (or maybe decoder ID
would do that), and look at the families. They they might realize
that it's a "CoolChip" decoder, select that family, and be close
enough to function.
Does this sound like it could help?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
CV8 seems to be the most reliable data but I'm not sure what they do
when a decoder is subcontracted like say Digitrax makes a decoder for Atlas
or similar.
One of the very large problems I see with anything that is done is the
availability of programmers. We have very few and need to recruit
more<VBG>.
I see we have another Jon (I like that name<G>). Jon, as you work in
the software development industry do you fit in the above needed category?
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
|
Jon, as you work in the software development industry do you fit in the above needed category? Unfortunantly, I'm not a Java Developer. Actually, I don't get to develop code much at all these days - I've evolved into more of a "Professional Meeting Attendee" and "Creator of Pretty Charts and Diagrams". One thing I am interested in trying is to port JMRI over to the PalmOS platform (using IBM VisualAge/Java Micro Edition); although, I don't know how successful this kind of endeavor would be. Jon Davis
|
At 9:27 PM +0000 5/31/02, jondavis76051 wrote: One thing I am interested in trying is to port JMRI over to the PalmOS
platform (using IBM VisualAge/Java Micro Edition); although, I don't
know how successful this kind of endeavor would be. Sounds like an interesting project. Although I've not looked at it in any detail, I think most of the communications stuff should go over pretty cleanly. So you'll be able to talk to the various DCC command stations over the Palm serial port (which we know can speak the LocoNet rate) You'll probably have to rethink the GUI, because the existing stuff takes _way_ too much space for a Palm screen. You'd probably also want to recode it without Swing, just to save space. That's a good idea anyway, as the works should be independent of the GUI on general principles. Let me know if there's anything I can do to help. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
At 9:27 PM +0000 5/31/02, jondavis76051 wrote:
One thing I am interested in trying is to port JMRI over to the PalmOS
platform (using IBM VisualAge/Java Micro Edition); although, I don't
know how successful this kind of endeavor would be. Sounds like an interesting project.
Although I've not looked at it in any detail, I think most of the
communications stuff should go over pretty cleanly. So you'll be able
to talk to the various DCC command stations over the Palm serial port
(which we know can speak the LocoNet rate) I have got a long custom HotSync cable for my Palm to do something with Java and JMRI on it. I wondered about just displaying a throttle Widget on the Palm with most of the work being done on the PC. However I have gotten distracted by these little uControllers and so my Java on Palm ideas are parked...
|
Bob Jacobsen