Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Form field description placeholder is too limited #3793

Open
tuxpiper opened this issue Oct 18, 2019 · 10 comments · Fixed by ushahidi/platform-client#1358

Comments

@tuxpiper
Copy link
Member

@tuxpiper tuxpiper commented Oct 18, 2019

Which user group(s) are the primary audience for this feature/enhancement.
Account-managed Ushahidi Platform customer.
This org distributes sophisticated forms for data collection nation-wide in the U.S.A. through a partner network.

Is your feature request related to a problem? Please describe.
The placeholder that allows deployers to describe each of the field is limited in terms of size (256 characters) and format (it doesn't allow or present line-breaks).

This doesn't allow enough expresiveness to introduce reporters to nuanced questions or situations. Sometimes this context is key to ensure more accurate responses to the survey as a whole.

Describe the solution you'd like
The field description placeholder should be changed to allow larger text sizes and present rich formatted texts (i.e. via rich text editor, or at least Markdown)

Describe alternatives you've considered
An alternative solution to the same problem, which wouldn't require altering the definition of this database row, could be to introduce a new type of survey field.

This new type of survey field, let's call it "help text", would be presented at report time and not require response from reporters. It would be there just to be displayed inline in the survey. It should allow lengthy text and support rich formatting (and presentation of links).

This alternative is further explored in a different issue (#3794)

@Erioldoesdesign

This comment has been minimized.

Copy link

@Erioldoesdesign Erioldoesdesign commented Oct 21, 2019

Mostly copy pasting the conversation & files from the slack thread.

Right okay - I've been wrapping my head around this request. It's very... specific and actually not something you can do in many form/survey generators (google forms/typeforms etc.)
So what they want is to have long descriptions for questions in their survey that have more than just text so:

ticket-3793- Form-field-description-formatting

I think the tricky this to design here is how other users, other than this user learns how this feature functions. It's just not very expected in form creation to have this amount of flexibility (not to say it isn't useful!)
So, the big lift design wise on ticket #3793 is the process in the survey creation section.
#3794 (Allow inserting blocks of content at arbitrary points in the form) actually would be harder to 'understand' from a user perspective without a lot of tutorial/onboarding. The adding of the arbitrary points in the form with the tutorial/learning would have to live in the 'edit field' section (below) which is...an odd place to put such flexibility and I'm not sure how useful that would be for more users.

Screenshot 2019-10-21 at 09 38 27

If we were going to do #3794 I would want to have this designed/built as a larger (i hate to use this word) re-design or deeper look at the flow of survey creation/build

Anna says: Could we make the user choose between short and long/more complex description in the description-edit field? The short one as default and the more complex one to choose between? Or does it become too much clicking?

Eriol in response: Hmm I would say if we're going to make the 'edit field' section have more text formatting available I would just make that default and go with something that looks like...this:

edit-field

I know in the ticket we've suggested making markdown supported...this would remove the need for a 'text editor' but I'm very skeptical at the widespread use/knowledge of markdown and that again, we're adding/extending a feature that requires some hand-holding tutorial work and/or most people (other than this user) wouldn't use.
Markdown would be an acceptable stop-gap for the description field as long as we provide an external link & text that says 'If you want to format your field description more, you can use markdown (link) to add bullets, titles and links in the text you add' like this:

edit-field-2

So this would be the least intense design wise. In fact I think this is the design pretty much.

@Angamanga

This comment has been minimized.

Copy link
Contributor

@Angamanga Angamanga commented Nov 1, 2019

@rowasc @tuxpiper @Erioldoesdesign Have attempted to spec above solution, the trickiest thing turned out to be finding a WYSIWYG library that outputs markdown, most libraries output HTML, would that be an ok option?

  • Update instructions-column in form_attributes to be of type text in the db + where needed in the backend
  • Find library to handle wysiwyg in the fe and that saves as markdown (was hard, see below)
  • Update description-input in settings/surveys/attribute-editor to be wysiwyg
  • Update description display in the main/posts/detail/post-value-edit views to display markdown (possibly use the same method as the markdown field-type) or HTML.

Libraries for WYSIWYG
I have researched WYSIWYG editors that are easy for the user to understand and saves markdown and it was hard to find! The only one I found was this one: https://ghiscoding.github.io/angular-markdown-editor/#/reactive-editor. You cannot preview the actual formatting, you see the markdown in the editor, which may be confusing for users.

The other option is to use an editor that outputs HTML instead:

Quill (This is my preference):
https://quilljs.com

Examples with Angularjs:
https://codepen.io/lenmorld/pen/yXrmBY
https://github.com/KillerCodeMonkey/ng-quill

Plus:

  • Open Source
  • Can remove formatting-options easily
  • Actively maintained (latest released 9 Sept 2019).

Minus:

  • Outputs HTML
  • IS actively maintained but have been working on version 2. for a long time without releasing, may indicate low involvement?

Trix:
https://github.com/basecamp/trix

Examples with Angularjs:
https://github.com/sachinchoolur/angular-trix
http://embed.plnkr.co/C4BTOHLoXV55lXDJ1tKh/

Plus:

  • Actively maintained (latest release 17 Oct 2019)
  • Free (MIT License)

Minus:

  • Seems tricky to remove formatting-options
  • Outputs HTML
@Angamanga

This comment has been minimized.

Copy link
Contributor

@Angamanga Angamanga commented Nov 7, 2019

@Erioldoesdesign A question I noticed about the behavior of the description-toggle (and also the default-value-toggle). As it is now, the toggle is never switched on, even if there is a description, which is a bit confusing to the user, so I want to change that. See screen-recording here: https://recordit.co/JCEisus45G

My questions and assumptions are:

  1. When there is a description saved, the toggle should be green and the description field visible in the editor, is that right?
  2. If the user turns the toggle off, even if there is a description added to the field, should that description be deleted or saved?
  3. If still saved and the user turns the toggle off, should that description be shown in the post-add-view or not?
@Erioldoesdesign

This comment has been minimized.

Copy link

@Erioldoesdesign Erioldoesdesign commented Nov 7, 2019

most libraries output HTML, would that be an ok option?

If this is the best option (because wysiwyg editors are poorly supported) I would say yes, HTML output works. We can test and review. :)

When there is a description saved, the toggle should be green and the description field visible in the editor, is that right?

Yes! if the user has previously added a description to that field then it should be defaulted/remembered as 'on' and show the editor.

If the user turns the toggle off, even if there is a description added to the field, should that description be deleted or saved?

Hmm...trickier...I would say it should be deleted/removed if the toggle is 'switched off' but there should be a modal/warning message before that happens. 'This action will delete your description text. Ok, delete the description. Cancel, do not delete the description.
(sorry for adding in an extra thing to code...)

If still saved and the user turns the toggle off, should that description be shown in the post-add-view or not?

I'm not sure I understand this question, can you do a video of this 'post-add-view' you say?

@Angamanga

This comment has been minimized.

Copy link
Contributor

@Angamanga Angamanga commented Nov 8, 2019

@Erioldoesdesign

If still saved and the user turns the toggle off, should that description be shown in the post-add-view or not?

So, what I meant was, if the description is saved in the form here, even if the toggle is turned off:
Screenshot 2019-11-08 at 09 00 14

Should the description be visible here then:
Screenshot 2019-11-08 at 08 59 19

But if we delete the description when the toggle turns off, issue is resolved, there is no description to show :) I can use the same delete-warning as in the data-view when moving away from edit-mode without saving

@Angamanga

This comment has been minimized.

Copy link
Contributor

@Angamanga Angamanga commented Nov 8, 2019

When thinking about it, I like the idea to control the visibility of the description with the toggle instead of text in the form, in that way there are less clicks and warnings and the user can choose if they want to start working on a description, leave it there and turn the toggle on when ready. Would that be ok?

@Angamanga

This comment has been minimized.

Copy link
Contributor

@Angamanga Angamanga commented Nov 8, 2019

After chatting with Eriol we decided to go for the solution where the toggle decides if the description is shown in the post-add/edit view or not.

@Angamanga Angamanga mentioned this issue Nov 11, 2019
5 of 6 tasks complete
@rowasc rowasc reopened this Nov 14, 2019
@rowasc

This comment has been minimized.

Copy link
Contributor

@rowasc rowasc commented Nov 14, 2019

@Obadha2 can you try this in steve-buscemi in the morning?
In addition to the testing checklist please check this field description is working well with a couple of paragraphs worth of text as well.

Testing checklist from Anna:

  • Go to settings-survey

  • Add a new survey

  • Add a new field, or edit title or description

  • A markdown editor should appear below "Add field description (optional:)":
    Screenshot 2019-11-11 at 10 43 38

  • For fields where it's possible to add a default value (all field-types except "upload", "description", "title" and "tags"), the default value box should be displayed with no toggle-switch:
    Screenshot 2019-11-11 at 10 46 28

  • Add some text in the description-editor, format it however you want to, and as long text as you want to

  • Save the field

  • Save the survey

  • Choose to add a new post to this survey

  • The description should be visible for the field you added description

  • The description should have the same formatting as you did in the editor

  • Save the post

  • Go to data-view

  • Select the post you added and select "edit"

  • The description should be visible for the field you added description

  • The description should have the same formatting as you did in the editor

Repeat the above steps for a survey that already exists

@Obadha2

This comment has been minimized.

Copy link

@Obadha2 Obadha2 commented Nov 15, 2019

QA'd, passes. 👍

@rowasc

This comment has been minimized.

Copy link
Contributor

@rowasc rowasc commented Nov 15, 2019

💯 💯 💯 💯 💯 THANK YOU all. Let's deploy this on monday morning !

@rowasc rowasc assigned rowasc and unassigned Obadha2 Nov 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.