|
In fact, it's worse than that, but that's all you can say on this forum.
The basic problem is that you have multiple alternates - interspersed with multiple comment/replies - on one page.
My solution: treat each Alternate as a separate sub-Tip. Each sub-Tip will have its own page. When you're looking at a list of Tips, what you will see is the original Tip, and indented beneath it, a list of sub-Tips (Alternates). Each Tip and sub-Tip will be displayed with its rating, so you can quickly go to the highest-rated Tip in that group. Currently, if you look at the list of Tips, only the rating of the original Tip is displayed, even though one of the Alternates might have a kazillion 5's.
Benefits:
1. List of Tips will show ratings for original Tip and sub-Tips (it doesn't now).
2. Comments for each Tip and sub-Tip will be on that Tip's page; less chance for confusion.
3. Same approach could be extended to Articles; there could be sub-Articles, for extensions, etc., and this would be very handy for "abandoned" Articles. Having the comments on the sub-Article page would also eliminate confusion about which version of the Article was being discussed.
4. There would only ever be one "approval menu flag" per page, and that would always be at the top of the page for the Tip/Article (not in the middle of the page for Alternates like it is now).
Comments?
|
|
|
|
|
yes, showing everything at once sometimes is too much, it is true for some tips, as well as for some Q&A (which I will not elaborate on here). On the other hand, splitting it up over multiple pages would not be my preference, as it involves even more paging and clicking.
I probably would consider an approach based on something that is or resembles a TabControl: the first (initially the only) TabPage would hold the original tip (with its own comments and discussions), the other (optional) TabPages would each hold one alternative (with its comments and discussions). The TabPages should have a fixed and simple order: chronological. The tabs themselves should show a text ("tip", "alternative 1", "alternative 2", ...), the original author, and some indication of appreciation (score, maybe also "most appreciated"). The number of TabPages might be unlimited in which case one needs to allow for multiple rows of tabs, or it could be limited to say 6, which means no more than 5 alternatives can be added, which would be fine by me.
While entering a new alternative, I would like to be able to see everything that is already present, so the entire TabControl should be available and operational.
While entering a comment/reply/... to an existing tip or alternative, it would be nice to also be able to see any part one chooses (i.e. the original tip or any of the available alts), however this would probably be harder to achieve, unless the editor itself would be on the relevant TabPage, which then has the disadvantage one can temporarily tab it away, while it contains unfinished input.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
What would you suggest for linking to the alternate tips on the original tips' page?
Luc's idea of tabs is interesting but I think would be too cluttered.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: I think would be too cluttered.
why is that? it probably would only take an half-inch band, see what you now have for articles[^] ("Article", "Browse Code", ...).
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Your original idea was to have text with "tip", "alternative 1", "alternative 2", etc, the original author, and some indication of appreciation (score, maybe also "most appreciated").
That's a lot of stuff to stick into a tab.
How about just having a floating box at the top right of the tip with a list of alternate tips as an unordered list:
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
your example kind of proves adding author and score on a second line does not really widen the tabs (except for some extreme member names, like JSOP); it mainly adds some height, that is why I said half-an-inch, not quarter-of-an-inch, and "a TabControl or similar".
I trust you could find a way to use a little panel as the tab content instead of a simple string, and stuff whatever it is you like in there? So far I never tried that myself...
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code. modified on Tuesday, May 10, 2011 11:15 PM
|
|
|
|
|
Tabs are not the answer; they're just not scalable. What if you had 30 Alternates? There would be 3 or 4 characters on each tab. That would be totally useless, and irritating as hell to anybody trying to use them.
|
|
|
|
|
A TabControl with a number of TabPages is exactly what is required here; it is an excellent way of grouping related stuff, and showing it, page by page, in a structured and well-understood way.
Decent TabControls support multi-row tabs; I just saw Dev Express has one. And anyway, a tip that provokes dozens of alternatives isn't worth a dime in the first place, when there are more than five alternatives, then there wasn't really a problem to begin with.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Your solution assumes an ideal Tip with an ideal number of Alternates. When it doesn't happen that way, guess what? We'll have another mess.
We can fix this with a solution that's scalable and easy to understand and use. Tabs just won't work in this situation.
|
|
|
|
|
Even better: Next Tip in Thread and Prev Tip in Thread buttons at the top and bottom of each Tip, which would make this flexible and expandable.
I think Luc's idea would be good for some situations, but not this one. For example, it's missing the key feature of being able to see all the sub-Tips, and see what the ratings are for the Tip and its sub-Tips.
Also, there are other UI features that could be implemented to make this scheme more user-friendly. Example: make the list of Tips incorporate collapso/expando buttons for those Tips with sub-Tips; this would make it easier to find the topic that interests you, and then you could drill down to the sub-Tips.
As I think about it, the more I'm convinced that this approach would lend itself very nicely to Articles, too. It would solve some of the more obvious problems, like people who want to extend the original article; and it would also provide a way to deal with "abandoned" Articles.
An added plus is that it would provide clean-looking, compatible and consistent handling for both Tips and Articles.
|
|
|
|
|
I think the first thing to do would be have the comments contained in a collapsible frame with the number of comments shown next to the expand/collapse control e.g. Comments (xx) View/Hide
The default would be hidden.
|
|
|
|
|
That would help the clutter but provide no other benefit. Just a bandaid.
|
|
|
|
|
Bandaids are good.......they stop my children crying when they are broke.
|
|
|
|
|
Until they fall off...then the scab is exposed...it's scratched...there's blood everywhere...infection sets in...the wounded limb removed...parents and well-wishers cringe at the horrible, disgusting, mutilated sight...nothing is the same, ever again. Depression ensues.
|
|
|
|
|
Scab picking is so satisfying 
|
|
|
|
|
Great. That's what I'm going to be thinking next time I make a change.
No pressure.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
I know that I, for damn certain, didn't type my post into this[^] site and yet there it is - CP ripped.
|
|
|
|
|
They have bigger ads than CP though. 
|
|
|
|
|
Great.
We'll send a nastygram. That's just rude.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
I occasionally provide a bad link in my messages, typically pointing to the local copy of one of my articles, rather than the link to the publicly available article. Therefore my suggestion is this:
whenever a URL contains "//localhost" or "//127", just show a MessageBox to the composer, telling him the link is suspicious. Somewhat similar to the reply-to-self approach.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
0 Bug: If you set two tags in your filter (eg Windows, API) it displays this text at the top of the page: You're viewing entries on the topics WindowsAPI. Note the missing delimiter between the two. Note the lack of a colon before the list.
1 Inconsistency: Also it seems inconsistent that Interested tags are listed at the top, but Ignored tags are not.
2 Inconsistency: Interested and Ignore are different tenses; you should use the same for both. 
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
Dan Neely wrote: 1 Inconsistency: Also it seems inconsistent that Interested tags are listed at the top, but Ignored tags are not.
I actually like that... why would I want the tags that I'm not interested in up there? Specially since there are a ton of tags...
|
|
|
|
|
Well spotted. Fixed, and will upload ASAP
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Just noticed there's no WinAPI or Windows API tag in the Q&A section. 
|
|
|
|
|
There's specific Windows versions, and an API tag. I expect a combination of the two would suffice.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
