GNOME Bugzilla – Bug 590666
Improve "Create Document" context menu
Last modified: 2012-08-12 15:13:44 UTC
The present method of creating new documents is not user-friendly: 1: User has to rename a file 2: User has enter the extension of the file type he wants to create. 3: User has to open the file after the initial select of > Create Document. 4: Editing the name of the file creates un-necessary 0 bytes empty backups 5: if the user renames the file *only* after editing , an empty "new file" exists 6: No-one actually simply creates an empty file, users want to work on the new Documents. Ubuntu seems to go about "fixing" this problem by adding an extra package which creates templates [https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/372132/comments/36] But one size doesnt fit all, every user needs a different file as a template [students> odp , studio > video/music empties , grahpics designers> svg , ...] And templates are not empty files, Templates are supposed to be user or company specific , something that already has a format, and just needs a minor edit to be finished. This issue has been debated several times over and devs have rightly refused to add templates by default... An elegant user-friendly solution needs to be achieved, which: 1: Allows the user to choose which templates to exist in the context menu 2: Opens the template instantly when the user selects from the context menu. 3: Prevents unnecessary empty backups To achieve this: 1: when user installs any new program [which allows creating documents,presentations,music,videos] the App must ask the user if the user wants templates to be installed in the context menu. a: user selects either from the file extensions he want to use regularly or from the templates which exist in the program. 2: Allow this menu to be customizable[which items exist and in which order] 3: When the user selects an item from the context menu, a: open the app directly with the empty file type selected, b: the file is saved in the location the user has selected the context menu, c: backups are created only after the first save[this should be achieved since this menu now behaves like opening the app from the applications menu or selecting a new file] 4: Adding custom templates to users ~/Templates directory, adds them to the context menu a: Allow these to be re-ordered but not deletable from the context menu editor[to avoid accidental deletion of the user's custom templates] b: Deletion of these custom templates is only from the ~/Templates directory. c: Do not show "No templates installed" in the context menu if user has not created any custom templates. 5: On the desktop , move "Create Document" context menu item one position higher to be located as the second item [above Create Launcher] 6: When apps are uninstalled , remove its entires.[this is a given but just mentioning] Other information: Related discussions: http://mail.gnome.org/archives/nautilus-list/2008-June/msg00123.html http://mail.gnome.org/archives/nautilus-list/2008-June/msg00139.html http://article.gmane.org/gmane.comp.gnome.nautilus/3745
Created attachment 139805 [details] Mockup Attaching a mockup of the idea.
*correction* in the list of problems* 4: Editing _the file_ creates un-necessary 0 bytes empty backups [not name of the file]
I'm not sure I like the idea of a prompt when installing applications (they install automatically currently and I think we should keep it that way) but this sounds good otherwise!
(In reply to comment #3) > I'm not sure I like the idea of a prompt when installing applications (they > install automatically currently and I think we should keep it that way) but > this sounds good otherwise! > The suggestion for the prompt during install was because, users might install several apps , but use only a few frequently Use case, example: user might install Avidemux for occasional video edits but might not need it for regular use, populating the create document list would not be ideal for such users.
I understand the benefit but I think it has worse consequences. 99% of applications install without user interaction at the moment, I don't think we should change that. Use case, example: Users don't want to have to read and answer a question for every desktop application they install.
I agree with some of those topics. 1.- I think this would be too annoying and not helpful. For the sake of speed the users probably would end up saying "YES" to everything. 4.c- Instead of the "No templates installed" a link to the templates folder.
(In reply to comment #6) > I agree with some of those topics. > > 1.- I think this would be too annoying and not helpful. For the sake of speed > the users probably would end up saying "YES" to everything. > > 4.c- Instead of the "No templates installed" a link to the templates folder. > Templates are rarely used by users, this menu item is not needed when there are quick links , only displaying the templates when they exist is better. If users dont realize how to use Templates folder, The templates folder could have a ribbon on top similar to the Trash folder , with a button "How to use Templates" which opens a Help documentation. (In reply to comment #5) > I understand the benefit but I think it has worse consequences. 99% of > applications install without user interaction at the moment, I don't think we > should change that. > > Use case, example: > Users don't want to have to read and answer a question for every desktop > application they install. > Ah... users might not read... very true. The main reason i had added a prompt as a control was ,the nautilus devs were very reluctant to allow apps dumping links in the context menus. Well... Since the user can later edit the items in context menu , Not having an initial prompt sounds good too... :)
An additional info bar in the Templates folder ? inform they can add templates there? Or maybe we can just remove the option from context menu when there are no custom user templates. ;) [ Just a follow up , Ubuntu will not be "fixing" this problem by adding an extra templates package. ]
Based on the last comment. I think this can be dup'd to 558435. *** This bug has been marked as a duplicate of bug 558435 ***