On Sat, Mar 14, 2009 at 9:36 PM, TK Soh <[email protected]> wrote: > On Sun, Mar 15, 2009 at 2:24 AM, Steve Borho <[email protected]> wrote: >> On Sat, Mar 14, 2009 at 9:20 PM, TK Soh <[email protected]> wrote: >>> On Fri, Mar 13, 2009 at 12:34 AM, TK Soh <[email protected]> wrote: >>>> On Thu, Mar 12, 2009 at 2:23 AM, Steve Borho <[email protected]> wrote: >>>>> On Wed, Mar 11, 2009 at 9:13 PM, Steve Borho <[email protected]> wrote: >>>>>> On Wed, Mar 11, 2009 at 7:33 PM, TK Soh <[email protected]> wrote: >>>>>>> I just tried the new changeset e24dd34219bc. While it seem more >>>>>>> helpful than tooltips, I am afraid it made the dialog look really odd >>>>>>> to me, and even (pardon me) somewhat ugly. >>>>>>> >>>>>>> I don't know if this is best way to handle this. For now, I'd feel >>>>>>> perhaps it would look better if locate within the notebook page, right >>>>>>> on top of the option areas. >>>>>> >>>>>> You can't really put it at the top because the description >>>>>> sizes vary so much (it makes everything bounce around). >>>>>> >>>>>> And putting it directly below the options just looks strange, so I >>>>>> compromised and put it at the bottom of each notebook page. >>>>>> Even this isn't without side-effects as two of the fields on the web >>>>>> tab can cause render overdraws, >>>>>> >>>>>> I'm open to other ideas on how to do this, but I do want the text >>>>>> visible. No-one reads tooltips if they can avoid it. >>>>> >>>>> What about making the dialog geometry more square and putting >>>>> the description frame to the left of the option list? >>>> >>>> Having given it more thought, I don't really feel that it's quite >>>> redundant, apart from the cosmetic issue. In most, if not all, cases, >>>> users only need to learn about an option once, since it's not hard at >>>> all to remember what the option is meant for once we learn about it. >>>> This is what the tooltips is good for - providing the info if needed, >>>> but doesn't take up the space or disrupt the layout of the GUI. >>>> >>>> If there's really any concern about clarify, maybe a help button that >>>> bring up the help doc like some apps do will be better. That way we >>>> will have more flexibility. >>>> >>>> On a remotely related topic, we are going to have to trust the users >>>> on their ability and responsibility to learn. It's not all that >>>> different from learning the CLI of mercurial. To me, making the GUI >>>> more elegant and intuitive is more important that worrying that user >>>> can't remember the purpose of the the text box, checkbox, etc. >>>> >>>> It's your call. These are just my 2-cent. >>> >>> BTW, can you point us some application out there that are already >>> doing what you did, so we can benchmark them a bit? >> >> I don't follow. Benchmark what? > > I meant to learn it from others that have done it this way. Maybe > benchmark is the wrong word.
It's modeled more after an installer than anything else. For each optional part you can chose, there's usually a text description of it displayed in a separate label. If TortoiseHg and Mercurial had really good documentation for all of their configurables, I wouldn't worry too much. But having just tooltips wasn't enough for me. -- Steve ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
