Closed Bug 49861 Opened 24 years ago Closed 23 years ago

Remove/reword Interview/Demonstration items or consolidate into one help page

Categories

(Toolkit :: Form Manager, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: fixed on branch)

Attachments

(4 files)

Build ID: 2000082208

I personally feel that the end-user won't have any idea what the "Interview" 
and "Demonstration" menu items in Tasks | Privacy and Security | Form Manager 
do.  I know I didn't have a clue, and I don't consider myself the average 
user.  "Interview" was especially ambiguous.  When I finally found out what the 
items did (lead to informative help pages, tutorials, and demos), it seemed to 
me that such items would be more appropriately placed in a help file somewhere, 
which would be more intuitive (if a user needs help on a feature, will they 
consult their help file or click menuitems labeled 'Interview' 
and 'Demonstration' ?)

SO...

I think we have four choices here:

(1) Change the wording of the items so they're more informative ("Interview" 
especially).

(2) Consolidate the two items into one broader "Help" or "Help on this Feature" 
(or somethin' like that) which would lead to a general informative help page 
about the Form Manager, with further links to (and more much-needed description 
about) the Interview and the Demonstration.

(3) Remove the menu items all together and put the pages, with more descriptive 
information, into the help file in the page that contains information about the 
Form Manager.

(4) Ignore me and mark this bug WONTFIX -- er, this is a bad choice. ;)

Am open to ideas...
Blocks: 48860
Interview is not supposed to be a lead-in to "informative help pages, tutorials, 
and demos".  It is indeed an interview form.  The user can use this form it 
initally populate his wallet data.  That has nothing at all to do with the help 
system.

So I'm not really sure why you were confused by "interview".  Could you try to 
be more specific as to why that confused you.

You are right in that the user probably won't have any idea initially as to what 
"demonstration" is.  So when curiosity gets the better of him, he'll click on 
it and get the pages which should be self explanatory.  If the explanations on 
those pages are confusing, please indicate what in particular confused you.
No longer blocks: 48860
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Ah. Sorry.  I get it now.  I thought Interview was just another sample form 
where you could enter some information, then prefill it on the same page as 
another form of demonstration.  So it's a place where you can enter all kinds 
of information in common form fields that are likely to show up later on in 
other forms?

<thinks...><ponders wontfix...>

I guess "Interview" is the best we can do here?  Also, the page 
that "Demonstration" links to is, er, quite hard on the eyes (the text is huge, 
and the page is pretty ugly...).  It's also pretty outdated, using terms like 
Wallet, and referring to menu items that have since been relocated.

Why was the dependency removed?
I thought that using a large font made the demo page easier to read.  Guess I 
was wrong.

I just prettied up the demo page a bit.  Didn't need to wait for tree opening 
because these are checkins directly on the server.  You can even try it out 
immediately (well wait about half an hour for it to be pushed outside the 
firewall) with your current build unchanged.

There is only one reference to "wallet" and that is in the title line.  It was 
put there because of the catchy iliteration (4 w's).

The reference to menu items that have since been removed is necessary because 
this is on the server.  Anyone running beta2 will get this same page and the 
wording needs to be correct for them as well as for people running the 
post-beta2 code.  After we release beta3 and beta2's timebomb goes off, we can 
remove the old references from this page.

What dependency removal are you talking about?
Closing this out because I believe that I've addressed all the items presented 
here.  Namely:

1. Clarified to the reporter why it was called "interview"
2. Prettied up the demonstation page.

If there's any issues here that I missed, then reopen this report or file a new 
report.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
And I made one more change that I forgot to mention.  I also removed from the 
demo pages the references to the old menu items.  I was able to do this because 
I just I moved the demo pages from the server to the client.  So now we can keep 
the wording on the demo pages in synch with any changes in the client.
Steve, `Clarified to the reporter why it was called "interview"' is only a 
legitimate fix for this bug if you're prepared to give the same explanation to 
every other user of Mozilla who comes across this submenu. Making the UI better 
requires an order of magnitude less effort than doing that, methinks. Reopening.

First, we need to ask: is anyone going to bother filling out a page full of 
personal information? That's a large investment of time for a user to make, 
especially if it only saves them ~20 seconds for any given form. (Even if it 
saves them time in the long run, they won't realize that). I think it's much more 
likely instead that a user is going to appreciate Mozilla gradually learning 
forms fill-in data from real Web forms as the user fills them in. And if that's 
the case, `Interview' should be blown away altogether.

Alternatively, if people are indeed going to use `Interview', it should be a 
`Forms Data' chrome dialog, not a Web page. If left as a Web page, users (not 
knowing what `chrome://' means in the location field) are going to be left 
wondering just who they are sending all this personal information to.

And as for `Demonstration', that belongs in extra help documentation on 
mozilla.org (above and beyond any help documentation shipped with Mozilla). 
Demonstrations of features (except for debugging purposes) shouldn't be bloating 
the Mozilla installation.

[Restored the magical disappearing dependency.]
Blocks: 48860
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
spam: mass-moving open password manager (single signon) and form manager
(autofill) bugs to Terri for qa contact. unfortunately, i cannot cc myself with
this form, so feel free and add me if you want to keep me in the loop with any
(but, pls not all :) of these... will also go thru 'em meself, a bit later...
QA Contact: sairuh → tpreston
Summary: Remove/reword Interview/Demonstration items or consolidate into one help page → [x]Remove/reword Interview/Demonstration items or consolidate into one help page
Target Milestone: M20 → ---
Summary: [x]Remove/reword Interview/Demonstration items or consolidate into one help page → Remove/reword Interview/Demonstration items or consolidate into one help page
Whiteboard: [x]
This bug report talks about a lot of things, many of which have already been 
addressed and fixed.  The only outstanding item that I can find is the issue of 
the interview form.

I have just changed the interview form from an html document to a xul document 
and it now comes up as a dialog and not a full window.  This was done for 
localization reasons (bug 51102) but it addresses the last remaining issue here 
as well.  The patches for the changes are currently sitting in that bug report 
and will get checked in just as soon is it works its way through the approval 
process.

Besides handling the interview functions, the new interview dialog also performs 
all the functions of the current dialog that you get from 
tasks->privacy->form-manager->view-captured-data.  So the patch throws away that 
dialog, has the new interview dialog come up when that menu item is selected, 
and removes the interview choice from the menu.

Since all of this work was done under the umbrella of 51102, I'm marking this 
bug as a dup of that one.

*** This bug has been marked as a duplicate of 51102 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
verifying as a duplicate of 51102
'[L12y] Please convert HTML files in wallet to XUL & DTD'
Status: RESOLVED → VERIFIED
Whiteboard: [x]
*** Bug 80342 has been marked as a duplicate of this bug. ***
Adding vishy and tpringle to cc: list.
Reopening bug, because IMHO blakeross issues weren't about L12Y, but deal with
the use of HELP information (i.e. Tasks | Privacy & Security | Forms Manager |
Demonstration) in a high level/visible menu item. "Demonstration belongs in help.
Status: VERIFIED → REOPENED
Keywords: nsbeta1
Resolution: DUPLICATE → ---
Vishy - It appears that I am not the only person who feels this way about
"Demonstration". Recommend we move it to help for M0.9.2.
Status: REOPENED → ASSIGNED
Target Milestone: --- → Future
Accepting the following piece for mozilla0.9.2: remove the Demonstration menu 
item under Tasks > Privacy and Security > Form Manager. This is a 
difficult to localizable set of html files. If mozilla has a problem with 
removing this menu item, we can do it in commercial only. 
Target Milestone: Future → mozilla0.9.2
Keywords: nsbeta1nsbeta1+
Whiteboard: one to two days of work here
nav triage team:

This is not a mozilla0.9.2 stopper, moving to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Vishy - As we discussed this is a 15 minute fix, that would prevent hours of 
localization work and costs. Pls move back to M0.9.2 and fix ASAP. We shouldn't 
push the cost onto other folks here.
Marking as nsCatFood.
Keywords: nsCatFood
We can not easily hide this menu item without causing damage to the utiltiy of 
the feature. Add'l it would costs $$$ in translations costs for each language 
and geogrpahy, L10N engineering and QA resources to support this "link". 
jaime - by pdt stopperness definition this bug didnt fit, hence moved to m0.9.3
limbo phase. in any case I'll attach a patch. 
Assignee: morse → vishy
Status: ASSIGNED → NEW
Thanks for the patch Vishy. It'll be good to have for the first limbo. Low risk
- - High reward here.
Keywords: nsCatFood
Whiteboard: one to two days of work here → patch ready, will attach
Keywords: nsBranch
Whiteboard: patch ready, will attach → eta 7/6 on trunk.
Blake and Ben: could one of you r= and the other sr=. thanks! Vishy
Keywords: patch
Whiteboard: eta 7/6 on trunk. → patch attached, need r=, sr=, PDT+, eta 7/6 on trunk.
Whiteboard: patch attached, need r=, sr=, PDT+, eta 7/6 on trunk. → patch attached, need r=, sr=, approval, eta 7/6 on trunk.
Cc'ing Sean for possible doc impact.
As module owner, I cannot approve of this change.  It is not what we agreed 
upon.  I frequently use the sample forms for debugging and we had agreed that 
any patch to remove the sample forms would do so for the release build only but 
keep them in for the debug builds.
Steve - could we take this patch for branch only and you can work on the better 
fix for the trunk? Actually one solution for the trunk may also be to move this 
whole item to a debug/qa menu. 
Whiteboard: patch attached, need r=, sr=, approval, eta 7/6 on trunk. → *nsBranch only* patch attached, need r=, sr=, approval, eta 7/6.
Why don't we do it right the first time -- it's not that difficult.  We can't 
use "#if DEBUG" statements in the xul file, but we can test for a hidden pref.  
That might even be preferable.  Total time needed to write and test such a patch 
is about an hour.  Therefore I still stand by my initial comment of not 
approving the current patch that you have posted. 
Steve - I'm not familiar enough with Wallet to produce the patch you would 
prefer. Could you point me to some js I need to hook into and perhaps where you 
made similar change for the form manager panels. That will simplify things for 
me. Alternatively could you take this bug, but we shd get this in on Monday. 
thanks! Vishy. 
Steve can you get the reviews soon, that would help. I'm a bit concerned since 
this patch is fairly large compared to commenting out some XUL. I'd still prefer 
the patch I submitted for the branch only. 
Vishy, please review.  cc'ing alecf for sr.
if (pref.GetBoolPref( ..)) - is this the right pattern or shd it be 
pref.GetBoolPref() == PR_TRUE?? Does the wallet.debug pref always exist?

This patch looks more risky to me for the branch at this point. I'm inclined to 
go with the first (static) one. 
This patch looks generally okay (except I believe we should be using 
nsIPrefBranch, not nsIPref), but I cannot see the rationale behind making this a 
pref.  Why can't we just remove it on the branch and continue to improve the 
situation for the trunk?  Looking to the future, I can't see why the final 
outcome would involve this being controlled by a pref.
> Does the wallet.debug pref always exist?

No.  That is why the code is inside a try..catch block.
As per PDT discussion today, we will take the first patch (XUL commenting fix) 
for the Netscape branch. The bug will remain open for the trunk to get to the 
right fix.  
Whiteboard: *nsBranch only* patch attached, need r=, sr=, approval, eta 7/6. → [PDT+]*nsBranch only* patch attached, need r=, sr=, approval, eta 7/6.
Jatin/Rudman - adding you to the Cc in case there is any doc impact. 

Montse/Ray - adding you to the Cc so that you are aware of this change - you do 
not need to localize this anymore. 

Reassigning to Steve to get the other fix on the trunk. 

Removing PDT+ and nsBranch as this is done for the branch now. 
Assignee: vishy → morse
Keywords: nsBranch
Whiteboard: [PDT+]*nsBranch only* patch attached, need r=, sr=, approval, eta 7/6. → fixed on branch
Thanks Vishy! Much Appreciated.
Where is this functionality available now?
Added patch which put wallet samples in debug menu as suggested by vishy.  This 
latest patch needs to be done in conjunction with vishy's patch of 7/5 (remove 
demonstration from [tasks] menu).

vishy & blake, please r and sr.
Status: NEW → ASSIGNED
OS: Windows 98 → All
Hardware: PC → All
r=vishy if you move the hardcoded string into the right dtd. 
vishy, this is debug code and does not need to be translated into other 
languages.  Furthermore, the pages that the menu item bring up are not localized 
(that's the reason we moved it out of the optimized browser).  And, finally, 
that file contains numerous hard-coded strings for the same reasons.

So do you really want me to use a dtd string here?
I dont really mind if its not localizable in this case (as it is debug), just 
would be nice to have it in a dtd as the nearby entities are also in dtds. If 
that is hard to do, r=vishy as is. 
The "very nearby" entries may be in dtd files.  But if you go out just a few 
more lines you will see many more entries, all of which are hard coded.  No, 
it's not hard to put this into a dtd file, but it means changing yet another 
file and for no valid reason.
sr=blake
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
Verified no Interview/Demonstration items under the Privacy & Securiy/Form Manager
Linux commercial build 2001-07-24-05
Mac commercial build 2001-07-24-03
W2k commencial build 20010-07-24-06
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
Product: Core → Toolkit
QA Contact: tpreston → form.manager
Target Milestone: mozilla0.9.3 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: