(search results : table editor) Prevent user edition errors in Table view with an Edit mode

[jroland01]

I have been rethinking about the ability to directly edit search results in Table Edit view : I believe one of the downsides is that each time you run a query, you are exposing the database's records to potential mistakes from users (inline editing as they browse through the results). What do you think ? Alternatively, we could have 2 base views : grid view, and list view, and a batch edit mode (Table Edit) that is accessible form these views, using a link (to make it explicit to the user that she is entering an edit mode, with consequences).

[jroland01]

OK. Is this how it is going to work ? : 1 - A user wants to edit a cell, 2 - User does a mouseover the cell, and an "Edit" button appears, 3 - User clicks on "Edit" and cell becomes editable, 4 - User edits cell, 5 - User explicitly clicks on "Save" button (appears in cell edit mode). 6 - Cell is updated.

OK for 2 views : Grid View (Light table), and Table View (incl. cell level editing, described above).

[kilchenmann]

The table view is only possible if the user has filtered the search results by only one resource. Otherwise the columns wouldn't be displayed correctly. The columns depend on the resource properties.

[loicjaouen]

It would really be great to be able to mix linked objects to review and edit them in a table format (#224)

and to select facets of composite types to export (#229)

It would be a real plus.

[jroland01]

@milchkannen I am not sure I understand the link between the issue raised (Edit mode in Table View) and the fact that it is not possible to mix-up resources in Table View ?

[kilchenmann]

You wrote:

we could have 2 base views : grid view, and list view, and a batch edit mode (Table Edit) that is accessible form these views

And I meant: The batch edit mode (table view) is only accessible, if we filter the results by one resource. Otherwise the button to change the view should be disabled. Or perhaps we can open a dialog box where the user has the chance to filter the search results by the resource.

@loicjaouen Yes it would be a real plus. But how can we display it?

[jroland01]

@milchkannen OK. I understand. So it's a different issue than the one initially raised in this thread.

I think faceted search could help here. Imagine that the first facet is "Resource type" (very similar to LinkedIn Search, see below), if you click on "All" (in LinkedIn : "Tout") then "Table View" button is disabled, if you click on one of the resource type "Authors", "Books", "Bibliographies", etc. (in LinkedIn : "Personnes", "Annonces", "Entreprises", etc.), then "Table View" button is enabled.

[mrivoal]

Regarding Table edit, I think what Loïc said is important. It is not only a real plus, in my opinion, for Salsah 2.0, it is very close to a requirement. And I think, if we can find a solution, both in Salsah and Knora to extend search functionnalities (#227), it will be usefull to extend the functionnalities of Table edit

1. At some point, Table edit could be a way for user to check, edit and enter data more quickly than any other current view in Salsah. The point is some of their data are intrinsequally connected. As a consequence, Table edit would be pointless for users if, along with a list of Books (as a resource), with their title and publication date properties, they cannot as well see the resources Author linked to them, with their name and country of birth property, for example.
2. Users will need to preview their data before they export hem in a .csv format. Table edit could be a great tool for this.
3. If Table edit is used as a tool to set parameters prior to data export, then Table edit should allow users to export metadata but also the representation files attached to them: images, pdf, etc., which is not currently supported.

[kilchenmann]

Yes it's important and I'm thinking about how we can solve the problem. I already have an idea in my head but not yet on the paper. I will draw it soon. By the way: the user should be able to export the data from every view, not only from the table editor view.

[jroland01]

@mrivoal @milchkannen Understand and agree with 2. and 3.

Regarding 1., I guess a question is how far you need to go in Salsah with this ? Does adding linked resource data through e.g. adding columns need to be handled directly through Salsah's interface ? Would it be enough to do that as part of the export process (user chooses the additional linked data to export) and let users handle the rest in a CSV editor (like Excel) ?

@milchkannen A question linked to that : What's the status regarding batch importing / updating through a CSV file ?

[mrivoal]

@jroland01 Yes, I think it could be enough as long as you only want to export data... But you want to update, edit, etc., then it would great and less time consuming for users (and especially project admins) to be able to edit data directly in Salsah.

What's the status regarding batch importing / updating through a CSV file ?

I don't know what you think of this, @milchkannen, but in my opinion, it is typically the kind of functionnalities that could be nice to have" in some future version of Salsah, but, right now, it would be a pain to implement (and conceive because it involves data modelling and to be able to deal with this in a generic tool looks really tricky). Consequently, I wouldn't place it in our top priority list.

[mrivoal]

(sorry for closing the issue prematurely... I still need to get used to Git)

[jroland01]

Just a few questions regarding bulk edit/update with Table View :

• Do we plan to support "Search & Replace" within Table View in Salsah (e.g. update all occurrences of a misspelled word, change capitalization) ? Or will this not be useful for some reason (e.g. data entry validation) ?
• Do we plan to support multiple tools such as e.g. zooming in, zooming out, horizontal scrolling, filtering, full-screen view (remove menus and stuff) to make it comfortable for the user to work with large tables (as Excel is) ?
• Do we plan to address the needs of researchers gathering data "in the field" with no or limited Internet (e.g. rural area, no internet credentials in library) ? Or is this not an issue ? Otherwise, importing an Excel file could prove very useful.

[loicjaouen]

@milchkannen

Yes it would be a real plus. But how can we display it?

something like this?

[kilchenmann]

Nice idea. But where in the workflow selects the user the property columns? Just an example of the photo resource in the SGV project: sgv:image has 18 properties with four resource-pointers (sgv:collection with 9 property fields (with resource-pointers again), 2x sgv:person with 24 properties, sgv:album (9 properties) and sgv:similar-image). This would produce a table with at least 75 columns. Or I'm wrong?

_Graph view of SGV_01P01070

Whats about cardinality? A book with more than one author (0-n)?

[jroland01]

@loicjaouen @milchkannen To what extend is the visual representation for adding resources and properties required ? Are the resource and property labels somehow evocative of what a user will be looking for ?

I would suggest using a "search, suggest-as-you-type and add through checkboxes" solution like the one used in Gmail labels (to add as many labels as you want to emails). This would probably scale much better, but I am not aware of all the requirements :

If you have Gmail, you can try if you haven't already.

[loicjaouen]

@milchkannen :

This would produce a table with at least 75 columns. Or I'm wrong?

You are right; that's why you want to somehow aggregate part of the info if you can, to work on a "projection" of your data.

Whats about cardinality? A book with more than one author (0-n)?

Yes... that's an issue. A tough one.

About exploration of RDF data: have a look at: https://www.youtube.com/watch?v=LY6taR3MuGI

[loicjaouen]

@jroland01 : search as you type and check boxes; it should be tried, or simulated against an example, same arguments as in search issue #227 .

[jroland01]

@loicjaouen

• What do you mean "tried or simulated against and example" ? Prototyped with data from a real project ?
• What do you mean with "same arguments as in search issue #227 ?

[loicjaouen]

@jroland01

Prototyped with data from a real project ?

yes, that would be great, imho.

"same arguments as in search issue #227"

I mean that both issues share the same source: how to display the web structure of our data. We either choose:

• a graphical representation where a node either buds on a new edge of the web or expands as a sub-form
• a textual representation where we list links' labels and print them either as auto-completion/suggestion or checkboxes

Don't you think so?

[jroland01]

@loicjaouen I guess I understand what you mean. As I see it there are several questions in there, e.g.

• How much does a user need to know about the web structure of your data to perform a specific task ? E.g. does she need to have a full representation of all nodes, properties, relationships in 2D to add columns to a Table View - or is a simple list of property labels, with e.g. one level of hierarchy enough ? The richer the representation, the more you "load" the user with information and choices, which may lead to confusion, less efficiency, etc. A good design should aim for a "sweet spot" where you show the user just enough from what's underneath so that she can do what she needs to do. At some point any interface is an abstraction layer and removes from the richness of the underlying data structure.
• How much power does a user need to have to perform her tasks ? E.g. our discussion regarding a the expression -based language. In a way or in another there is a tradeoff that needs to be made between power and complexity or learning curve. If you want a tool that can leverage the full power that Salsah/Knora allows, this tool will probably require skills and learning, whichever way you implement it (form/GUI, expression -based, etc.). This is why a continuum of tools is probably required for search (faceted/form based, search/logical operators, full expression based), and each tool will make different tradeoffs depending on the skills of the user (normal, expert) and the the kind of search she is doing. I don't believe that we can find one search solution/tool that is both easy to use, makes users want to search in Salsah, and at the same time allows all the possibilities that Salsah/Knora allows (e.g. lilke @benjamingeer's example of stainglasses). I guess we need to accept that some tools will be limited (on purpose), even though "some users may want to do X and Y in addition". Otherwise, there is a risk that we end-up with a labyrinthine system.
• Different interaction techniques have different advantages and purposes. E.g. forms for free text search, facets to quickly drill-down and understand your data, auto-suggestion to remove frictions and build on a user's latest, saved, etc. queries, text -based search/logical operators to build more complex logic, rich visual representation to explore or associate data. We probably need to combine these techniques, depending on the purpose, e.g. :

(1) search using facets to drill down into the data + some form fields for free text search + search/logical operators if the logic requires it ?

(2) adding columns through a combination of visual representation (like the one you suggest) + search/filter as you type to remove, filter out when you have complex models (this is e.g. done in some MindMapping tools like iThoughtsX on the Mac) ?

Etc.