GUI to create foreing objects
|Assignee:||Alexander Blum||% Done:|
|Category:||-||Estimated time:||1.00 h|
|Target version:||Repertoire 1) Testing phase I|
Sidenote for Meik: I renamed "2nd level objects" to "foreign objects" to emphasize the relation issues.
We have two object creation processes, which need to enable the user to create objects of others, see Specification.
Especially for the creation of Creations the corresponding GUI/Form is quite complex:
- Our database has to be queried
- Future feature: additional dabases should be queried (e.g. musicbrainz)
- Additional information should be provided for disambiguation (e.g. artists with the same name)
- If no match was found, a new object should be specified (artist: name, email; creation: name, artist)
- Unclaimed objects created by a web user should be editable afterwards
Right now, I see four options for the implementation:
1. One Form + No Database requests (~3h)¶
We skip the database request part.
- The form is easy to implement with standard forms
- We might get lots of duplicates to handle later on
- The invitation of other artists would not be reasonable
2. Several Forms (+ No Database requests) (~10/30h)¶
We split the specification of relationships to other objects into several forms.
- Group members can only be added after the Artist was created (e.g. an "add" icon on the artist details page)
- Contributors and originals/derivatives can only be added after the Creation was created (e.g. an "add" icon on the creation details page)
- This would break down the complexity
- This would be more error-prone as the user is not stictly guided anymore (could be countered e.g. by notes or big icons on the object details page).
- The form for database queries would still need to be hand crafted, although we have more degrees of freedom (e.g. to change the whole form, if there's no match).
- We could omit the database queires in the beginning (like in option 1) to save time (~20h)
3. One Form + Wizard (~40h)¶
We defere the creation of foreign objects and divide them into steps.
- The form class of portal would enable us to implement something like this.
- This could break down one complexity but add another
- There should be feedback for the steps (e.g. 3 artists and 2 creations left)
- The assocation should be clear (this artist is the contributer for lyrics, etc.)
- We might be able to reuse parts of the usual forms
- We could offer the whole form, as the user might be willing to provide more information
- I would not be convinced to call this a nice gui
- The implementation might need similiar time as the 4th option
4. One Form + Layover (~50h)¶
We provide a complete hand crafted form.
- The main object creation form
- A dropdown list for database queries with autotype selection
- More information on mouseover (ajax calls)
- An "add" icon in the dropdown, if no match was found
- A layover with the form for foreign objects on "add"
- Creation of the foreign object after submission (ajax call)
- Refresh of the dropdown list and autoselect the new object (ajax call)
On one hand, we have limited time for the implementation on the other hand, the creation form is the core of the metadata part of repertoire.
I would cross out option 3.
If we have time, I'd prefere option 4.
Otherwise I would vote for option 2 without database queries and add those, if we have time left. Those could be developed into option 4 (with ajax calls) later on.
Opinions? Other proposals?
#2 Updated by Meik Michalke over 4 years ago
- Assignee changed from Meik Michalke to Alexander Blum
I would vote for option 2 without database queries and add those, if we have time left. Those could be developed into option 4 (with ajax calls) later on.
yes, starting with a basic 2 and then moving towards 4 over time sound like the way to go for me: gets us to a generally usable result rather quick, but also includes a plan of improvement for the future.