Page MenuHomePhabricator

[Story] Grammatical Forms look like faked statements
Closed, InvalidPublic

Description

In T162790 we created an ugly but editable version of editing the grammatical features of a Form. We now want it to make it pretty. It should have a similar look to statements. (But it should not have references, qualifiers and ranks. The property part of the statement is not an existing property and not linked but instead hard-coded text.

Mockup:

Acceptance criteria:

  • The grammatical feature part of a form seamlessly integrates with its statements.
  • I can view and edit existing grammatical forms.
  • I can add new grammatical features.

Previously open question:

  • Do we need a selector for novalue/somevalue?
    • No we do not.
  • Does the order of grammatical statements matter? Or: should grammatical features be stored and displayed in the order they're entered? Or in any other particular order?
    • The order does matter for display but we are going to do this the same way we handle it for statement ordering for now (ie with a global list that gives the order).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 12 2017, 11:44 AM
WMDE-leszek renamed this task from [Story] Grammatical Forms as faked statements to [Story] Grammatical Forms look like faked statements.Apr 18 2017, 12:49 PM
WMDE-leszek updated the task description. (Show Details)

@Lydia_Pintscher @daniel :

The title says "Grammatical Forms look like faked statements" – does that summarize the problem or goal here? From what was said in the engineering time it seems to be a problem; From what is written in the ticket, making it "look like a statement" is the aim.

daniel closed this task as Invalid.Apr 25 2017, 1:31 PM

After a conversation with Lydia yesterday, it seems like treating grammatical features "kind of like" statements is not useful:

  • features have no ranks, no novalue/somevalue, no qualifiers, and no sources.
  • features act as a "description" associated with the form, like the class and language of the Lexeme.

Closing this as invalid for now, pending further UX design.

To work on it I would need some insight in how we assume the proposed/existing UI would impair the use (in some sort of realistic scenario, like "When a user wants to do… they assume … because currently … this leads to…")

For the record: by closing this as invalid, I don't mean to say "we will not use this solution". I'm just saying that the UI design should be discussed some more, and alternatives considered.