Switch to fragments mode

[benel]

Description

What is the valuable outcome that cannot be achieved with current features?

For which stakeholder (people, role, project, domain) is it important?

Which user action should be enabled (or restricted)? For who?

Additional details (solutions you think about, or workarounds you tried)

Deliverables status

Phase 1

• Scenarios (Gherkin)
• Mockups
• Implementation strategy

Phase 2

• Acceptance tests (Capybara)
• Implementation

Phase 3

• Screencast

[GuillaumeGilles42]

does the fragment view make sense for picture documents or other type than cassandre end lasuli?

[benel]

does the fragment view make sense for picture documents or other type than cassandre end lasuli?

@GuillaumeGilles42 You shoud ask @Hypertopic/if05-p19.

[vl-gx]

Related Mockup :

[benel]

@liyangsifei

In the fragment part of this view (right side), it shows only the fragment related to the sub-category selected or the item with the fragments colored?

Last week, I got that your team had decided (at last) to show all the fragments at the same time.
Always design the most simple solution (esp. there is a risk that the "enhanced" version is worse for users than the simple one). It seems that @valentin-utt's mockup goes in this way.

@valentin-utt This is an interesting mockup, however I see that you decided to group fragments according to topics rather than according to memos. Is there a reason for this? I find it quite surprising since:

• we don't understand then the link between fragments and memos that are displayed,
• the links between topics and items (and then fragments) are already handled (much more powerfully) by topic selection (and please note that grouping and selecting are very similar in their use).
• this is not compatible with the existing display therefore it will require more work by coders to implement it and by users to understand it.

A much simpler design would have been a basic table-like layout for grouping fragments with their related memo. Did you consider it?

[vl-gx]

Thank you for your advice, a simpler way of grouping the items could be this way :
Maquette V2 :

[benel]

@valentin-utt

• Which fragment corresponds to which memo? The third one seems to be partly in David1 and in David2, which is incompatible with the definition of a fragment. OR are all of them related to David1 because it would be selected?
  Then I'm still unsure if all your team agrees on the way it should work. Last week, I got that your team had decided (at last) to show all the fragments at the same time (therefore with no item selection at all). Always design the most simple solution (esp. there is a risk that the "enhanced" version is worse for users than the simple one).

• A table-like layout doesn't mean that you should draw borders. It's just a way to use both the vertical and horizontal axes to show links or similarity between data.

[vl-gx]

The new version of the mockups (V3) are as follow :

Notice that the black mouse pointer symbolizes the link to the coresponding fragment in cassandre website. The items are not selectable anymore compared to previous version.

The second scrennshot illustrate the use of the topic section, the selection of one topic restric the table view to the linked fragments.

Which fragment corresponds to which memo?  Are all of them related to David1 because it would be selected?

This is what was planned with the previous version of the mokups.

  Then I'm still unsure if all your team agrees on the way it should work. Last week, I got that your team had decided (at last) to show all the fragments at the same time (therefore with no item selection at all). Always design the most simple solution (esp. there is a risk that the "enhanced" version is worse for users than the simple one).

Indeed, there was a misenderstanding about how we should display the fragments, the new mockups take this remark into account.

A table-like layout doesn't mean that you should draw borders. It's just a way to use both the vertical and horizontal axes to show links or similarity between data.

This is an interesting point, however after discussion with the team we choose to use borders to :

1. Make the separation between fragments more readable (some fragments are very short, on the others hand some can span multiple lines).

2. To clearly see with which item the fragment is associated with.

[arnaud9145]

This is what implementation looks like today