File Attachments

Proposed Date	One line description	Idea	Votes For	Votes Against	Status	Status Description
20 Apr 2004	Change file uploads so that selecting a file's action and then uploading a different filename will not create a new file	This has caused a lot of confusion in my company, even though right at the bottom of the action page it clearly says what is going to happen if they change the filename. It goes against the principle of 'least surprise' apparently. They are probably right, so I think this should be fixed. For example, you upload a file called a.txt. You then click on 'action' for that file, and decide to upload an updated version of that file. Your next version is a2.txt. You upload the file, but it doesn't get renamed on the fly and updates a.txt, it creates a new file in the file list called a2.txt. Confusing for StupidCorporateUsers. -- NathanOllerenshaw - 01 Jul 2003 I'm determined to fix this, as it is the last thing that my StupidCorporateUsers are complaining about. I've made a feature request at UpdateAttachmentsDontWorkAsExpected. -- NathanOllerenshaw - 02 Jul 2003 I concur, this would be a useful change. With a slight change in wording, it's not only stupic corporate users who get confused. -- MattWilkie - 02 Jul 2003	2	0	In Progress	This is an interaction flaw that should be repaired. Taken up by NathanOllerenshaw. See UpdateAttachmentsDontWorkAsExpected for progress.
20 Apr 2004	Make managing attachments more intuitive	The attachment management screens should work more like a normal file manager. * 'action' column should have 'view', 'move', 'rename', 'delete' links on each row. * 'attribute' column managed via checkmarks on each row. * No need to display 'Update attachment' - just allow for an upload. If the name is the same as an existing attachment, it's an update (warn user?). -- TomKagan - 27 Dec 2002 The main difference between a file manager and a web interface is that with the file manager you can change options real time, whereas on the web you need to submit your changes. So moving all attachment editing options to the attachment table would not make things always clear: when does the change take effect? Changing the properties of one attachment at a time makes sense. I do agree that visibility can be improved: * 'action' can be changed to 'edit'. See KOALAwiki. * View, Move, Delete ("Move to Trash") can be made buttons. If the bug above (Uploading a different filename should not create a new file) is solved, you can keep 'Update attachment'. Uploading a file with a different name should then replace the old file. -- ArthurClemens - 31 Aug 2003	2	0	In Progress	Changes proposed in PatternSkinCodeChanges . -- ArthurClemens - 31 Aug 2003
21 Apr 2004	add 'replace' button/action	"replace" on an existing file would 1) upload the new file, using the new name, 2) delete the old attachment, 3) (optional) rename the new file to the old name. "upload" would upload a new file, and use the name of the new file. -- MattWilkie -- 22 Apr 2004	1	0	Proposed

Searching

Date Proposed	One line description	Idea	Votes For	Votes Against	Status	text
20 Apr 2004	Make simple search look for all words (instead of phrase search)	At the moment simple search looks for the literal occurence of the phrase entered. In my opinion this is a usability problem as the average user is used to a different behaviour: When using search engines (e.g. google) the default often is to search for all words entered. Thus I propose to change the simple search to KeywordSearchWithImplicitAnd by default. -- DanielKabs - 10 Feb 2003 Updated: -- DanielKabs - 12 Feb 2003	1	0	Implemented	Feature implemented by KeywordSearchWithImplicitAnd and SearchScopeForTopicAndText and is scheduled for CairoRelease.
20 Apr 2004	Combine search in topic text and topic title	-- SamHasler -- 20 Apr 2004	1	0	Patch Available	Patch available at SearchSuggestion, by SamHasler. Suggestion: check code and include in Core, implement change in WebSearch.

Editing and topic creation

Date Proposed	One line description	Idea	Votes For	Votes Against	Status	text
20 Apr 2004	Automatically create new webs	Currently if you got to a topic in a web that doesn't exist you get the oopsnoweb page. It would be nice if it was configurable if you get oopsnoweb (which links to ManagingWebs where it can be created) or if it created the web automagically. -- SamHasler - 10 Feb 2004	1	0	Proposed
20 Apr 2004	Save in edit-mode should be designed more convenient	The normal user works on documents by using the Desktop-metaphor, which can also easily be applied to TWiki by "save" and "save & close" options during editing. (see BetterSaveBehaviour) -- AndreUlrich - 09 Feb 2004	1	0	Patch Available	Code for direct-save is already available -> SaveContentWithoutEdit and has only to be integrated into the TWiki-Codebase. User interaction has to be designed and translated to templates. -- AndreUlrich - 09 Feb 2004
20 Apr 2004	Redirect to WebTopicEditTemplate topic when clicking on question mark link	From Support Web: I would like to let the user select a template when creating a new topic. I understand (or think ) that this can be done by editing the WebTopicEditTemplate topic and adding a combo box containing all existing templates or whatever (see PerTopicTemplates ). But what if the user does not use the "Go" box to create the new topic but by adding a WikiWord and clicking the question mark? Can I somehow redirect to the WebTopicEditTemplate topic? (I would like to see a behaviour similar to that of MoinMoin Wiki, see http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi/WikiSandBox ) -- KlausNowikow - 25 Jul 2003 Should this become default behaviour? If you work with templates, then this would be a big improvement. If you do not, however, this will take an extra step. Implementation issue: if you have a combination of parent AND template selection on WebTopicEditTemplate (see DynamicEditTopicTemplate), some values have to get prefilled. -- ArthurClemens - 20 Aug 2003	1	0	Proposed
20 Apr 2004	Set "Release edit lock" checked by default	See comments at: PleaseUseReleaseEditLockCheckboxVariable -- ArthurClemens - 06 Jun 2003	1	0	Proposed
20 Apr 2004	Simplify deleting a page	As it is now, a page is deleted by 'moving' the page to the '_deleted' web. This is a little awkward. This 'move' should be hidden from the user with an action link. A 'delete' link should handle this transparently to the user. -- TomKagan - 27 Dec 2002	1	0	Implemented	Patch available in DeleteTopicShouldNotFollowIt. Patch is also applied in TWikiAlphaRelease and TWiki.org. Idea can be moved to OldUsabilityIdeas.
20 Apr 2004	Create a separate page for Delete	Deleting a page is currently done on the same page as Move and Rename. But you will never combine these actions on a topic. Less options == less confusion and better focus on the job to be done. Suggestion: create a separate template page for deleting topics. Same goes for Moving and Renaming. -- ArthurClemens - 17 Aug 2003 See also: TrashButton and DeleteTopicShouldNotFollowIt.	1	0	Proposed
20 Apr 2004	Reveal the actual to-be-generated link targets when previewing	Say that you are creating a link to some less trivial location, i.e. not just a wikiword, but instead using a plugin or some sort of %MACRO{foo}% to have the final target of the link resolved on-the-fly when viewing the page. Another example is when using this sort of link: <br />[[MyCoolPage][that cool page]]<br /> What is percieved as an unneccecary extra layer of implicity is the fact that you'll never be fully assured that generated links will point to their correct location until you have actually clicked "Save" and can view the results. I think that a really slick solution for this could be to generate a simple client side script to make the "resolved" link targets show up in the status bar of the browser instead of the rather unhelpful http://twiki.org/cgi-bin/oops/Blarf?template=oopspreview when hovering the respective links in preview-mode. -- ConnyBrunnkvist - 09 Feb 2003 If you limit the problem to "Make sure I create a correct link in edit mode", you can create a link to a pop-up window where you can browse the topics in the web, or maybe other webs as well. See for instance the pop-up in http://www.visiblearea.com/cgi-bin/twiki/edit/Patterns/Test_page (link "List of all topic names"). -- ArthurClemens - 09 Jun 2003	1	0	Proposed
20 Apr 2004	extend 'Edit' and 'Preview' to automatically unlock page when possible	A short javascript should be included on those screens hooked to the DOM onUnload() event. The script should be smart enough to not unlock when the user hits 'Back' from within the 'Preview' screen and to warn the user if they are about to discard changes. -- TomKagan - 27 Dec 2002 Why not just set the TWiki preference for topics to be unlocked-on-save by default? ( RELEASEEDITLOCKCHECKBOX = checked ) -- MattWilkie 28 Dec 2002 Sorry, I wasn't quite clear. The suggestion is about what happens when you abandon editing, not when you save your changes. The option box to which you refer works only if you click "save." Right now, the only clean way to abandon an edit is to click "cancel". Adding the javascript hook would automatically unlock the page for the other ways a user can abandon the edit ("back" button, closing the browser, typing in new url, etc.) Currently, any other action besides "cancel" leaves the page locked. I just spotted another case where another small Javascript can help. If a user saves a page, then clicks "back" to get to the previous edit, they are now working on an unlocked page. Hooking the another DOM event - onLoad() - on the edit page could tidy this up too without breaking the the wonderful cache fixes RichardDonkin implemented. -- TomKagan - 30 Dec 2002	1	0	Proposed
20 Apr 2004	Relative anchors (<a href="#anchorname">) should work in preview mode	Perhaps a few other anchor types should work in preview mode as well. -- TomKagan - 27 Dec 2002 I would like to see this. I would also like relative anchors to have a different class name so they can be stylised differently from regular links using CSS. E.g. <a href="#anchorname" class="alocal"&gt becomes dark blue, or whatever, instead of the regular link blue. -- MattWilkie - 28 Dec 2002 You can do this right now via CSS2 selectors, plus greater flexibility via CSS3 selectors -- TomKagan - 30 Dec 2002 Can someone show how? Or give a link? -- ArthurClemens - 10 Jun 2003 Anchor links can have a small icon after the link. I will investigate this. But I am not sure why anchor links should work in preview mode, and other links not. Someone has written a patch so that links in preview open a new window. -- ArthurClemens	1	0	Proposed

Improving TextFormattingRules

"More" editing

Layout

Viewing

URL topics

Distribution

User acounts

-- SamHasler - 20 Apr 2004

Sure, it makes adding easier! Small notes:

1. the one line description edit box can be higher, so you can read the whole description
2. where can I add my signature?

-- ArthurClemens - 21 Apr 2004

1. That would mean making it a textarea, and I was trying to keep it to one line. I was trying to keep the number of columns and their width when editing as small as possible. I'm tempted to remove the Proposed Date column and add it's width it to One line description.
2. The initial text for the Idea column in a new row is a signature. Again, I was trying to keep the number of rows to a minimum.

-- SamHasler - 22 Apr 2004

This makes adding entries a snap. I like it. Unfortunately getting them out is a pain -- for example the file attachments section has three or four good responses. They need to be pulled into a seperate topic so discussion, and hopefully consensus, can proceed.

(This isn't to say this edit table approach shouldn't be explored further.)

-- MattWilkie - 22 Apr 2004