Project

General

Profile

Actions

Feature #15256

closed

Workspaces Usability-Problem

Added by old_heldenschreck over 18 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Workspaces
Target version:
-
Start date:
2005-12-04
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

At first the new workspaces-module seems very nice and easy to be used.
But with further testing the three different versioning types (element, page, branch) and the inconsequent auto-versioning at offline-workspaces causes in my opinion some serious usability problems.

Examples:

1) New elements, editing existing elements and deleting elements is done by auto-versioning. But the same - for the user simple - action of moving an element presents an error message an needs the manual creation of a page- or branch-version. Its understood that these actions are necessary due to the technical background. But as a user I simply dont understand that concept.

2) User edits a page-title and the system creates an auto-version of the page. If the user later wants to move a content-element in the page or wants move the page, he can't. Not only he becomes some error message, but he also cannot create another version (in this case page- or branch-version) because there is one already an he must publish it first before he can make moving-changes.

I can only guess that this problem is hard to resolve because of the restrictions of the versioning concept. But at this moment the very nice workspaces are not very nice to use. It demands the user to know the limitations of versioning and that ist no usual acting for an author or editor.

(issue imported from #M1974)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Feature #16359: "merge version" feature for Web>pageClosed2006-07-18

Actions
Actions #1

Updated by Sebastian Kurfuerst over 18 years ago

Hi,
I just saw this entry on the bugtracker and noticed that neither of you monitored this issue. It would be awesome if you could have a look at it!

Thanks and greets, you are doing a great job,
Sebastian

Actions #2

Updated by Administrator Admin over 18 years ago

Hi there,

You have correctly described some issues that I know exists. Actually the tecnical limitations are not possible to bypass, we should rather look into interface changes that secures the user does not end up in the "trap".

For both cases I always planned the best way to solve them were with the input from users like yourself - thats why I didn't want to waste time with some random implementation I could not trust would work.

So; Please suggest how these issues can be changed on the interface level.

Thanks for caring for the issue btw!

Actions #3

Updated by old_heldenschreck over 18 years ago

Possible Solutions without changing the whole architecture:

1) Configurable error-messages. As I recall the error-messages are presently hardcoded in the source. There must be a way to translate and modify them and it would be good if the message names some workaround for the user (e.g. create a version and use alias to save the links when the page-id changes, call the helpdesk, whatever).

2) Configurable Auto-Versioning for page- and branch-versions, when changing the position of an element. Once the user knows about the risk of changing ids and with it the risk of broken links, he should be able to edit without the additional clicks to manual create version (maybe with reminder).

3) When moving a page and with it creating page- or branch-version is affecting an element-version (e.g. a changed page-title), is it possible to integrate/merge this element-version in the page-or branch-version?

4) Showing possible Link-Errors. When a page- or branch-version is created and it is not possible to auto-correct the links for the new id, maybe you can at least show the user some possible conflicts.

Question: Deleting an element is possible with an element-version, insert new elements too. Instead of versioning the whole tree when moving an element, would it be possible to delete the element on the old position and copy-create a new element on the target position? There is the same-id-Problem, but this could be done without page- or branch-versioning.

PS: Is it planned to change the architecture that is causing the problems within the 5.0-version of Typo3?

Actions #4

Updated by Administrator Admin over 18 years ago

Hi,

there are some other small usability problems. If an author get his changed Content-Element to the state "Review", he can not cancel it later. So if he recognize a mistake he has no chance to solve it, before the reviewer has a watch on it.

May be, it should not be possible to get the element back to the editing mode. But there should be the possibility to change the comment for this item.

The comment field should be textarea. If a content item is large, the comment can be it too.

Thanks and bye,
Michael

Actions #5

Updated by Administrator Admin over 18 years ago

Hi Guys,

For version 4.0 there is no way to fix any of these issues, we must look at it for 4.5 or later.
I don't know about an architecture change. The architecture is not flawed in my eyes; there is no way to get what you ask for without an incredible overhead.
You also point out some suggestions and usability issues as well; I agree with some of them and think we will work on it for the next version also.

Actions #6

Updated by Martin Kutschker almost 18 years ago

Problem 2 can perhaps be solved by the "merge version" feature described in bug #3866.

Actions #7

Updated by Martin Kästner over 17 years ago

Suggestion:
If a user would like to change the position of an element, the versioning could be done on element level with just create a new version for eveny element which the position (value) must be changed. Surely it could be many version created...

Actions #8

Updated by Tolleiv Nietsch almost 13 years ago

  • Category deleted (Miscellaneous)
  • Status changed from Accepted to Closed
  • Target version deleted (0)
  • PHP Version deleted (4)

Assuming that the mentioned concerns have be "fixed" with the changes shipped with 4.5.

Actions #9

Updated by Michael Stucki over 10 years ago

  • Category set to Workspaces
Actions #10

Updated by Michael Stucki over 10 years ago

  • Project changed from 624 to TYPO3 Core
  • Category changed from Workspaces to Workspaces
Actions

Also available in: Atom PDF