Hello list, This is notionally off topic, but I''m hoping this might be a common enough problem that others have or will encounter it in a Rails or AJAX context. I''ve got a many to many relationship between records in 2 tables: - table A has approx 9000 records - table B has approx 1000 records I need to allow users to manage the many-to-many linkages using the Web interface. These linkages won''t change that often, but they will change from time to time. Normally, for smaller tables, I''d do this by letting them select a record from table A, then providing e.g. a checkbox for each element in table B and letting them check or uncheck each box, which would in turn create or destroy the appropriate many-to-many links. This approach scales well up to (say) 20 records in table B, after which it becomes unwieldy. However, if I use this approach in this case, the user will see 1000 checkboxes, which isn''t practical for obvious reasons. Does anyone have any ideas of how I can implement this functionality from a UI perspective? Thanks in advance Dave M.
Knowing almost nothing about your data (and really, the nature of that is the most important factor) I would think that a good UI might step someone through categorized tiers of secondary (and possibly primary) records. This is obviously a fairly diverse set of data, and I imagine there are non-arbitrary groupings and a natural (or contingent) workflow to be recognized and addressed. Yeah? On Jul 20, 2005, at 10:07 PM, David Mitchell wrote:> Hello list, > > This is notionally off topic, but I''m hoping this might be a common > enough problem that others have or will encounter it in a Rails or > AJAX context. > > I''ve got a many to many relationship between records in 2 tables: > - table A has approx 9000 records > - table B has approx 1000 records > > I need to allow users to manage the many-to-many linkages using the > Web interface. These linkages won''t change that often, but they will > change from time to time. > > Normally, for smaller tables, I''d do this by letting them select a > record from table A, then providing e.g. a checkbox for each element > in table B and letting them check or uncheck each box, which would in > turn create or destroy the appropriate many-to-many links. This > approach scales well up to (say) 20 records in table B, after which it > becomes unwieldy. > > However, if I use this approach in this case, the user will see 1000 > checkboxes, which isn''t practical for obvious reasons. > > Does anyone have any ideas of how I can implement this functionality > from a UI perspective? > > Thanks in advance > > Dave M. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> Does anyone have any ideas of how I can implement this functionality > from a UI perspective?Speaking as a UI designer, I''d ask the same thing someone else here did: what''s the nature of the data? This is really not a technical or "functionality" problem at all, it''s an interaction problem. Although it sort of worries me; there''s a reason you probably can''t think of an existing UI to copy. Large sets of many-to-many items, while easy for programmers and computers, are rarely easy for end users. I''d wager your intuition is right. The appropriate interaction is probably something like the 20-checkboxes UI. A person can make a meaningful choice from 20 things. The trick then is figuring out how to eliminate the other thousand (or whatever) irrelevant choices beforehand. There''s got to be some way of categorizing some of those 10k records into smaller chunks.
> There''s got to be some way of categorizing some of those 10k records into smaller chunks.+1
The application involves asset management in a large organization (50,000+ people). This particular piece of the app involves managing assets (typically servers, discs, tape storage, SANs, etc.) and applications (e.g. SAP). Specifically, I need to be able to connect assets and applications. Normally, an application would have one to many assets attached to it (e.g. SAP may have 3 Oracle servers, a Web server, plus more). An asset may have several applications attached to it; a specific server may host databases for multiple applications, or we might be using something like VMware to host many virtual servers on the one physical server. What makes categorization difficult is that the "common name" of the application very rarely is related to something like a line of business. As with many large companies, the common name of an application will be something like "Gladiator" or "AFG", which contain no information about what the application does or which line of business it services (which *would* be sensible choices for categories). It may be that "AFG" is an abbreviation for something like "Apples For Geese", which would allow it to be classified under either "Fruit" or "Animals" (bear with me, I''m stretching for an example...), but no-one will refer to it as anything other than "AFG". I obviously need to categorise these applications on *some* basis, as Toby kindly pointed out. The only option I can see seems to be alphabetical categorization. As Andrew said, there''s probably a practical limit of ~20 checkboxes that a user could reasonably be expected to work with; 26 isn''t that great a stretch, given that it''s the alphabet we''re talking about and most people would know that e.g. "T" is going to be towards the end of the list. Thanks for all the responses. Dave M. On 7/21/05, Andrew Otwell <andrew-uQjPo4GTFqgS+FvcfC7Uqw@public.gmane.org> wrote:> > > Does anyone have any ideas of how I can implement this functionality > > from a UI perspective? > > Speaking as a UI designer, I''d ask the same thing someone else here > did: what''s the nature of the data? This is really not a technical or > "functionality" problem at all, it''s an interaction problem. Although > it sort of worries me; there''s a reason you probably can''t think of > an existing UI to copy. Large sets of many-to-many items, while easy > for programmers and computers, are rarely easy for end users. > > I''d wager your intuition is right. The appropriate interaction is > probably something like the 20-checkboxes UI. A person can make a > meaningful choice from 20 things. The trick then is figuring out how > to eliminate the other thousand (or whatever) irrelevant choices > beforehand. There''s got to be some way of categorizing some of those > 10k records into smaller chunks. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
When you say "select a record from table A" amd table A has 9000 records then presumably you have some kind of search dialog which shows a list from which they select a single record from table A? At that point, how about a similar search dialog to restrict the display from table B? But rather than displaying a from which to select a single record, your results list would have checkboxes appropriately set, and your controller would handle checking/unchecking as you described in your OP.
David Mitchell wrote:> The application involves asset management in a large organization > (50,000+ people). This particular piece of the app involves managing > assets (typically servers, discs, tape storage, SANs, etc.) and > applications (e.g. SAP). Specifically, I need to be able to connect > assets and applications. > > Normally, an application would have one to many assets attached to it > (e.g. SAP may have 3 Oracle servers, a Web server, plus more). An > asset may have several applications attached to it; a specific server > may host databases for multiple applications, or we might be using > something like VMware to host many virtual servers on the one physical > server. > > What makes categorization difficult is that the "common name" of the > application very rarely is related to something like a line of > business. As with many large companies, the common name of an > application will be something like "Gladiator" or "AFG", which contain > no information about what the application does or which line of > business it services (which *would* be sensible choices for > categories). It may be that "AFG" is an abbreviation for something > like "Apples For Geese", which would allow it to be classified under > either "Fruit" or "Animals" (bear with me, I''m stretching for an > example...), but no-one will refer to it as anything other than "AFG". > > I obviously need to categorise these applications on *some* basis, as > Toby kindly pointed out. The only option I can see seems to be > alphabetical categorization. As Andrew said, there''s probably a > practical limit of ~20 checkboxes that a user could reasonably be > expected to work with; 26 isn''t that great a stretch, given that it''s > the alphabet we''re talking about and most people would know that e.g. > "T" is going to be towards the end of the list. > > Thanks for all the responses. > > Dave M.Would the person making the associations between the applications and equipment know enough about each to be able to ''type it in'' rather than select it from a visible list of options? If so, how about the user selects the left side of the relationship (be it an app or equipment) and then is presented with an auto-completing textbox to select the right hand side. They type roughly what they are searching for in the auto-complete box and choose the correct item from the list. Pressing ''enter'' or clicking a button adds this item to the relationship, whereby focus is restored on the auto-complete textbox for more additions. Hope this reads as clear as I have the picture in my head, and that it may be of some use. Chris
On Thursday 21 July 2005 18:22, Chris Roos wrote:> Would the person making the associations between the applications and > equipment know enough about each to be able to ''type it in'' rather > than select it from a visible list of options? If so, how about the > user selects the left side of the relationship (be it an app or > equipment) and then is presented with an auto-completing textbox to > select the right hand side. They type roughly what they are > searching for in the auto-complete box and choose the correct item > from the list. Pressing ''enter'' or clicking a button adds this item > to the relationship, whereby focus is restored on the auto-complete > textbox for more additions.Like this: http://www.schuerig.de/michael/boilerplate/form_habtm.png I''ve got this working for weeks already, but don''t get around to release a new version :-( Michael -- Michael Schuerig Thinking is trying to make up mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org for a gap in one''s education. http://www.schuerig.de/michael/ --Gilbert Ryle
> Would the person making the associations between the applications and > equipment know enough about each to be able to ''type it in'' rather than > select it from a visible list of options? If so, how about the user > selects the left side of the relationship (be it an app or equipment) > and then is presented with an auto-completing textbox to select the > right hand side. They type roughly what they are searching for in the > auto-complete box and choose the correct item from the list. Pressing > ''enter'' or clicking a button adds this item to the relationship, whereby > focus is restored on the auto-complete textbox for more additions.I like this solution. However it suggest that the user have a level of familiarity with the data. For example, to get the Apples For Geese they''d need to already know that it''s filed under AFP. Heck, I think even tagging the assets a little could be helpful. tags that describe the asset... "application server" or "database" or "fruit stand" as well as maybe tags that describe what it "needs" ie: the SAP asset could have "needs" tags like "databases" "web servers" So the user would locate asset A through some kind of search (which could be aidded by the tags) and then it can populate some suggestions by polling for an asset B with tags like asset A''s need''s tags. The user could just disregard those still and fill out an autocomplete box with an option to not include tags in the search. Realistically I think your data has more information than just the name of the asset. What do people use this for? Is it to document configurations after the fact? Is it to create work orders? Is it simply to create network layout diagrams? Is it meant to demonstrate a need for better naming conventions? Do they use this every day? Does it replace a current process? Who uses the application? People very familiar with the assets? I don''t think the problem is that you have 10k records and you need a way to display them so that a user can manage them all from one screen. I think that (at least from what you''ve told the mailing list) you haven''t defined your problem well enough. Anyways, I hope that''s helpful. I look forward to hearing how it goes. Caleb
On 7/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Thursday 21 July 2005 18:22, Chris Roos wrote: > > > Would the person making the associations between the applications and > > equipment know enough about each to be able to ''type it in'' rather > > than select it from a visible list of options? If so, how about the > > user selects the left side of the relationship (be it an app or > > equipment) and then is presented with an auto-completing textbox to > > select the right hand side. They type roughly what they are > > searching for in the auto-complete box and choose the correct item > > from the list. Pressing ''enter'' or clicking a button adds this item > > to the relationship, whereby focus is restored on the auto-complete > > textbox for more additions.Yes, but perhaps by having a drill-down list for the asset types would help, too, i.e., +servers -phlegm1 -phlegm2 +database -oracle_10g -oracle_4.2 +storage -san_ity1 -san_ity2 +etc ...with multi-select capabilities, so that selected options are remembered even if they''re in a group that is shrunk down after items are selected. Or, have some sort of grouping of assets in different selection controls. Filtering could be helpful as well (i.e., run things through that Bayesian engine to classify them...).> > Like this: > > http://www.schuerig.de/michael/boilerplate/form_habtm.png > > I''ve got this working for weeks already, but don''t get around to release > a new version :-( > > Michael > > -- > Michael Schuerig Thinking is trying to make up > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org for a gap in one''s education. > http://www.schuerig.de/michael/ --Gilbert Ryle > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Yeah, the idea of an auto-completing text entry field occurred to me last night (my time) as well. It might be a good fit - I''ll put together a mock-up example, run it by some users and get their responses. Good suggestion - thanks Dave M. On 7/22/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Thursday 21 July 2005 18:22, Chris Roos wrote: > > > Would the person making the associations between the applications and > > equipment know enough about each to be able to ''type it in'' rather > > than select it from a visible list of options? If so, how about the > > user selects the left side of the relationship (be it an app or > > equipment) and then is presented with an auto-completing textbox to > > select the right hand side. They type roughly what they are > > searching for in the auto-complete box and choose the correct item > > from the list. Pressing ''enter'' or clicking a button adds this item > > to the relationship, whereby focus is restored on the auto-complete > > textbox for more additions. > > Like this: > > http://www.schuerig.de/michael/boilerplate/form_habtm.png > > I''ve got this working for weeks already, but don''t get around to release > a new version :-( > > Michael > > -- > Michael Schuerig Thinking is trying to make up > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org for a gap in one''s education. > http://www.schuerig.de/michael/ --Gilbert Ryle > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Thanks for the suggestion. However, the problem is that there''s not a lot of categorization of assets that can be performed, which will mean anything to the users. After doing a fair amount of digging, I''ve got the following categories potentially available for assets: - vendor name (e.g. HP, Sun, IBM, EMC, ...) - model name (e.g. 280L, DL450, ...) - environment (e.g. Production, Testing, Development, ...) Unfortunately, none of these are useful for the users I''m working with. The users are clerical staff; they don''t know an HP from a Sun, Production from Testing, etc. When there may be >500 assets that are "Sun E450", it''s difficult to choose between them. The only really (semi-)unique identifier they have for an asset is a serial number, which may be non-unique across the entire 10,000 assets from multiple vendors, which may have been entered incorrectly in the first place (i.e. it''s easy to mis-type something like "A00005CD0345B"), and which also means close-to-nothing to the app users. My guess is that probably 5-10% of serial numbers have been incorrectly entered. My understanding is that they almost need some sort of fuzzy logic module in their brain that lets them think "Hmm, didn''t find this serial number. Maybe the B was mistyped as an 8. Maybe the 1 was mistyped as an I. Maybe the 0 was mistyped as an O. Maybe, instead of typing 5 zeroes, they only typed 4...". Somehow, they nearly always find an asset when they''re searching for it. On that basis, an auto-completing text entry box may be the best solution. At least then, as they type in characters and narrow in on the right asset, they may be able to see that e.g. one asset has a missing digit, or nearly-but-not-quite matches a vendor''s normal serial numbering scheme. Lots of good suggestions in this thread - thanks very much. Dave M. On 7/22/05, Corey Lawson <corey.ssf.lawson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 7/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote: > > On Thursday 21 July 2005 18:22, Chris Roos wrote: > > > > > Would the person making the associations between the applications and > > > equipment know enough about each to be able to ''type it in'' rather > > > than select it from a visible list of options? If so, how about the > > > user selects the left side of the relationship (be it an app or > > > equipment) and then is presented with an auto-completing textbox to > > > select the right hand side. They type roughly what they are > > > searching for in the auto-complete box and choose the correct item > > > from the list. Pressing ''enter'' or clicking a button adds this item > > > to the relationship, whereby focus is restored on the auto-complete > > > textbox for more additions. > Yes, but perhaps by having a drill-down list for the asset types would > help, too, i.e., > > +servers > -phlegm1 > -phlegm2 > +database > -oracle_10g > -oracle_4.2 > +storage > -san_ity1 > -san_ity2 > +etc > > ...with multi-select capabilities, so that selected options are > remembered even if they''re in a group that is shrunk down after items > are selected. > > Or, have some sort of grouping of assets in different selection controls. > > Filtering could be helpful as well (i.e., run things through that > Bayesian engine to classify them...). > > > > Like this: > > > > http://www.schuerig.de/michael/boilerplate/form_habtm.png > > > > I''ve got this working for weeks already, but don''t get around to release > > a new version :-( > > > > Michael > > > > -- > > Michael Schuerig Thinking is trying to make up > > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org for a gap in one''s education. > > http://www.schuerig.de/michael/ --Gilbert Ryle > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
In article <f6508a860507211705498f9a6d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, monch1962- Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> My understanding is that they almost need some > sort of fuzzy logic module in their brain that lets them think "Hmm, > didn''t find this serial number. Maybe the B was mistyped as an 8. > Maybe the 1 was mistyped as an I. Maybe the 0 was mistyped as an O. > Maybe, instead of typing 5 zeroes, they only typed 4...". Somehow, > they nearly always find an asset when they''re searching for it.Sounds like they''re already doing this task (in some form) today. Is there some way to recapture some of the searching/organizing techniques they use into the new software? -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler