<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div id="smartTemplate4-quoteHeader">
      <style type="text/css"> #newHeader { font-size: x-small; } #newHeader b { font-weight:bold; color: #990033; } </style>
      <div id="newHeader"> <br>
      </div>
    </div>
    <blockquote class=" cite" id="mid_5053F725_9000907_gmail_com"
      cite="mid:5053F725.9000907@gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <link href="chrome://translator/skin/floatingPanel.css"
        type="text/css" rel="stylesheet">
      <div class="moz-cite-prefix">On 15/09/2012 4:22 AM, Kent James
        wrote:<br>
      </div>
      <blockquote class=" cite" id="mid_50537CD6_5030003_caspia_com"
        cite="mid:50537CD6.5030003@caspia.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        On 9/14/2012 11:23 AM, Patrick Cloke wrote:<br>
        <br>
        <blockquote class=" cite"
id="mid_CAC4yyp_C969BWvDRP3WFrpox1PLYDT55c_ud1_hwyZVg8xsLkQ_mail_gmail_com"
cite="mid:CAC4yyp=C969BWvDRP3WFrpox1PLYDT55c=ud1+hwyZVg8xsLkQ@mail.gmail.com"
          type="cite">
          <div class="gmail_quote">
            <div>  </div>
            I also wonder if some options don't necessary need UI and <a
              moz-do-not-send="true" class="moz-txt-link-rfc2396E"
              href="about:config">"about:config"</a> is a good enough UI
            for them. <br>
          </div>
        </blockquote>
        That is good for really rare choices, or cases where a minority
        disagrees with a decision (New versus Unread counts in the Mac
        summary is a good example of that). But some key players hate
        them on principle.<br>
      </blockquote>
      About config options are almost always buried in the comments of
      the bug.  They are not documented, until now support have had a
      policy of not documenting them in how to articles unless they
      must.  There are literally thousands of settings in <a
        moz-do-not-send="true" class="moz-txt-link-freetext"
        href="About:config">About:config</a>, If we are to start the
      process of deliberately placing advanced settings in <a
        moz-do-not-send="true" class="moz-txt-link-freetext"
        href="about:config">about:config</a> for the user to edit then
      it is time to ante up and document the ones that are already
      there.<br>
    </blockquote>
    You are giving me an idea for a new extension that makes access to
    them easier and documents them. I have a standard mechanism of
    exposing selected debug options by opening <a class="moz-txt-link-freetext" href="about:config">about:config</a> with a
    readonly filter (which is a very primitive and lazy way of making
    them accessible without building a new UI).<br>
    <br>
    <blockquote class=" cite" id="mid_5053F725_9000907_gmail_com"
      cite="mid:5053F725.9000907@gmail.com" type="cite">
      <blockquote class=" cite" id="mid_50537CD6_5030003_caspia_com"
        cite="mid:50537CD6.5030003@caspia.com" type="cite">
        <blockquote class=" cite"
id="mid_CAC4yyp_C969BWvDRP3WFrpox1PLYDT55c_ud1_hwyZVg8xsLkQ_mail_gmail_com"
cite="mid:CAC4yyp=C969BWvDRP3WFrpox1PLYDT55c=ud1+hwyZVg8xsLkQ@mail.gmail.com"
          type="cite">
          <div class="gmail_quote">
            <div> I don't think it makes sense to talk about this in
              overall terms.  I think it would be more useful to take a
              look at each feature individually and see whether it can
              be simplified / removed / etc.<br>
            </div>
          </div>
        </blockquote>
        A specific strategy of being more deliberate about pushing
        advanced features to addons is an overall issue, and the main
        point of this thread. Certainly we should strive whenever
        possible to keep user interfaces simple.<br>
      </blockquote>
      I don't think it is advanced features that is the problem, it is
      UI design.  </blockquote>
    + 1,000 !<br>
    <br>
    there is a lot of functionality in Tb already which is hard to
    access or understand from a UI stand point.<br>
    <blockquote class=" cite" id="mid_5053F725_9000907_gmail_com"
      cite="mid:5053F725.9000907@gmail.com" type="cite">When I am
      editing my account setup, there is no button to click to open
      passwords or outgoing servers for that account.  </blockquote>
    QuickPasswords actually does that for you - click an account in the
    folder pane and then the QuickPasswords button - it always tries to
    guess the context of what password you are looking for. but it would
    be trivial to add a button to the Server Settings page beside the
    user name field; and also the logical place rather than expecting
    the user to know that his function is compartmentalized into the
    Password Manager (one of the most hidden features of the Mozilla
    application universe).<br>
    <blockquote class=" cite" id="mid_5053F725_9000907_gmail_com"
      cite="mid:5053F725.9000907@gmail.com" type="cite">It is this sort
      of creaky decades old design that is the issue.  <br>
      Over in support land users are asking <br>
        * how to change a password (Microsoft have passwords, most users
      are x Microsoft software).  We hide this stuff so well that some
      are not even aware they have a password until it stops working.<br>
    </blockquote>
    QuickPasswords :-P <br>
    <br>
    It is funny I often get support mail that assumes I have written the
    whole Password Manager because people are not aware that it is built
    in and can be reached via Edit/Settings or Tools/Options. Managing
    Passwords is clearly an important piece of functionality, IMO it
    would deserve to be promoted to a  main  menu item. (Tools or Edit
    Menu)<br>
    <blockquote class=" cite" id="mid_5053F725_9000907_gmail_com"
      cite="mid:5053F725.9000907@gmail.com" type="cite">   * They want
      to know how to "export" their mail to move to their new device. 
      This is an area that needs action.  We have a full bodied data
      intensive application sitting on a machine that is these days
      often replaced in 12 to 24 months, that is if it does not simply
      let out the magic smoke in 6 months.  We have no migration path.
      Or backup strategy.  I know. backup is a machine thing.  Not any
      more.  Everyone copies their important stuff to USB.<br>
    </blockquote>
    +1 - my suggestion would be to <b>create </b><b>an extension for
      this first</b> (I don't agree an external utility like MozBackup
    is the best / correct way to approach this; it is just too techie to
    set up). then after doing UAT with the users continue to migrate
    into core.<br>
    <blockquote class=" cite" id="mid_5053F725_9000907_gmail_com"
      cite="mid:5053F725.9000907@gmail.com" type="cite">   * Where have
      their menu and toolbars gone (How can I send a mail my send button
      and it's whole bar is missing?)<br>
    </blockquote>
    Isn't the toolbar still shown as part of the vanilla setup? And the
    user get's a choice of whether to integrate this into the mail
    header pane instead?<br>
    <br>
    Sorry, I haven't looked at nightly lately.<br>
    <blockquote class=" cite" id="mid_5053F725_9000907_gmail_com"
      cite="mid:5053F725.9000907@gmail.com" type="cite">   * My account
      does not work and it has a padlock on it!  It would be funny,
      except for some providers our penchant for NOT using the account
      settings recommended by the providers does mean that padlock is
      indeed the reason their mail is not working.<br>
        *And they still don't get Tabs (Yesterdays description was a
      line of email addresses across the top of the page)<br>
      <br>
      None of those things are advanced features, but they are UI
      issues.  If the users just don't get it that our design is at
      fault.<br>
    </blockquote>
    Yes.<br>
      Axel<br>
    <br>
    <div class="moz-signature">-- <br>
      <style type="text/css">
.myName:hover { font-size:13pt; text-shadow: 3px 3px 4px rgba(200,250,200,0.7);}
</style>
      <div id="testSignature" style="width: 65%; padding: 0.8em 1.2em;
        font:x-small verdana; color: #444; box-shadow: 4px 4px 9px -2px
        rgba(0,0,0,0.65); border-radius: 1em; padding: 0.4em 2em;
        border: 1px dashed #444; background: rgb(230,240,163);
        background: linear-gradient(to bottom, rgba(230,240,163,1)
        0%,rgba(210,230,56,1) 50%,rgba(195,216,37,1)
        51%,rgba(219,240,67,1) 100%); background:
        -moz-linear-gradient(top, rgba(230,240,163,1) 0%,
        rgba(210,230,56,1) 50%, rgba(195,216,37,1) 51%,
        rgba(219,240,67,1) 100%);">
        <b class="myName" style="text-shadow: 1px 1px 2px
          #DDD;cursor:pointer;-moz-transition-property:font-size;
          -moz-transition-duration: 0.5s;">Axel Grude</b> [T]
        <br>
        Software Developer
        <br>
        Thunderbird Add-ons Developer
        <span style="color:#666666; font-size:xx-small">(QuickFolders,
          quickFilters, QuickPasswords, Zombie Keys, SmartTemplate4)</span>
        <br>
        AMO Editor </div>
    </div>
  </body>
</html>