Add and edit space image

[tbsbdr]

Description

User Stories

• As a spacemember I want to add a space image to the Space Frontage so that other members can find the space effortlessly.

• As a spacemember I want to add an image to the space so that it communicates the purpose of the space in a non-verbal way.

• As a spacemember I want to change the image of a space so that I can adapt it to a more suitable image when needed.

Value

• Enhance Spaces user experience
• Alternative possibility to communicate the purpose of a space eg. in a non-verbal way ("a picture is worth a thousand words")

Acceptance Criteria

• If there is no image yet: display a placeholder area next to the space title with a "Upload image" button. On click, the user can choose an image (png, jpg, animated gif etc.) from her local harddrive for upload.
• Location: The uploaded image gets stored in the root of the corresponding space
• Filename: The uploaded file gets renamed to "space_image" so that users can guess, that this is the current image of the space.
• If there is already an image set: display button "Upload new image" on the image; on click, the user can choose to upload an image form her harddrive as described above. The uploaded (updated) image overrides the old image (new version gets created implicitly)
• If the new image is of a different filetype, the filename of the old image gets "_old" appended (old image: space_image.jpg -> space_image_old.jpg; new image: space_image.gif) If space_image_old.jpg already exists, it gets overwritten and a new file-version is implicitly created.
• Rightclick on a supported image file within a space: context menu lists item "Set as Space image" (same icon like in the initial "upload image" button and like on the "Upload new image" button. image gets copied to the predefined path and overrides the former image. <-- we deliberately rejected this idea, because it would have required disproportionate efforts to implement this feature without obscuring to other space members, what file the current space image is.

Reasoning

We had some discussion about where to store space image and description. Unless there are good reasons, we should go with the described approach above.
Reasoning:

• By design, spaces are ment to be self-sufficient and robust which in our case means, that metadata like the image or the description should be stored within the space and not "outside" eg. in a extra metada-space.
• By design, severe, erroneous filechanges are prevented via file-versioning and not via restrictions amongst the space members.
• By design, spaces follow the paradigm of "Full Disclosure" rather than "Security through obscurity" amongst the space members
  --> Therefore Space image and description are getting full disclosured in the root of a space with a speaking name and not hidden in a .folder

Note: If real world usage proofs, that the described approach is prone to error, other, more restrictive approaches could be more helpful. Until we don't have real world experience with space image and description, we start with an "open" approach.

Assumption: If the image and description are stored in a .space folder, users will probably delete the folder because it seems superfluous to them.

Main approaches that where discussed

Approach 1

".space" contains image and description:

• only one item (folder) --> keeps the root tidy
• a default, fixed location where you can be sure to find the recent image and description

• ".space" is not very speaking folder-name, so users will probably delete the folder accidentally because it seems superfluous to them.
• As a folder, .space needs first to be opened to see its content -> It obscures its content in the first step.
• desktop-sync: editing the description file with a desktop app would be a little bit cumbersome (need to sync hidden files)
• .hiding files contradicts the "open paradigm" of Spaces

Approach 2

"space-root" contains image and description:

• Prevent deletion of files through full disclosure: specific file names and an image preview are more meaningful than a ".space" foldername, thus preventing users from accidentally deleting these files
• can be edited with desktop editors "out of the box" without having to sync hidden files

• irrelevant files might be perceived as distrubing in daily work

Approach 3:

"any file" can be set as image or description via right-click

• for first setup: Easiest and well known pattern (c.f. "set as desktop background")

• not collaboration-friendly: needs special hint/pointer/tags/etc to make clear, that "this file" is the spaceimage or description to prevent accidental deletion
• would still need a fixed location like root or .space for image and description that where uploaded via sidebar from the local disk (for Button "Upload space image").

Approach 4:

"Image and description as folder properties"

• image- and description file are not visible as files to the user
• image and description are then not only applicable to Spaces, but to every folder

Definition of done

• Functional requirements
  [ ] functionality described in the user story works
  [ ] acceptance criteria are fulfilled
• Quality
  [ ] codre review happened
  [ ] CI is green
  [ ] critical code received unit tests by the developer
  [ ] automated tests passed (if automated tests are not available, this test needs to be created and passed
• Non-functional requirements
  [ ] no sonar cloud issues

Initial: Add Space image

Update existing Space image (on frontpage)

Update Space image (via context menu) canceled - won't get implemented.

[tbsbdr]

updated description to latest discussion

[tbsbdr]

We'll go with the currently available implementation (store in .space, but no right-click option to set any file as image/description) --> #6410

The currently available approach (.space) will be demoed to the early adopters to gain feedback / iterate.