Project

General

Profile

Actions
Copy link

action #16376

closed

action #16062: [tools]Better user information about openQA changes

Dynamic user information about new openQA features

Added by okurz almost 8 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
krauselukas
Category:
Feature requests
Target version:
Milestone 8
Start date:
2017-01-31
Due date:
% Done:

0%

Estimated time:

Description

user story

As a frequent user of an openQA instance I want to have notifications about openQA to learn about new features which can make my work more efficient

acceptance criteria

  • AC1: There are notifications presented to web UI users when they visit an instance / page and there are new features which they have not seen / acknowledged
  • AC2: Acknowledgement of a feature notification makes it go away and not shown anymore for the user

tasks

  • research how other systems are doing it, e.g. github
  • prepare fields in database
  • do some bootstrap notifications thingies
  • provide a way for developers to put feature descriptions into openQA, at best somehow paired with documentation

further details

okurz: Had a nice chat with Artem (SCC) and now I am convinced we finally need a database storing user data, e.g. last visit, been informed about feature X, (and later personal preferences). The user is the king, let's treat him as such!

Actions
Copy link
 #1

Updated by krauselukas over 7 years ago

Interesting task, after a quick research i found this https://github.com/pickhardt/Guiders-JS which might be useful.

Actions
Copy link
 #2

Updated by okurz over 7 years ago

  • Target version changed from Milestone 7 to Milestone 8

At least it has been touched during M7

Actions
Copy link
 #3

Updated by krauselukas over 7 years ago

  • Assignee set to krauselukas
Actions
Copy link
 #5

Updated by krauselukas over 7 years ago

  • Status changed from New to In Progress
Actions
Copy link
 #7

Updated by krauselukas about 7 years ago

Current state of the ticket:

The base for the feature is implemented (using bootstraptour). Opened a PR for a first quick tour. Progress of the tour (seen or not seen) will be saved in the database, so users wont get annoyed by notifications they already been informed.

Next steps:

Add useful/interesting feature tours.

Actions
Copy link
 #8

Updated by krauselukas about 7 years ago

  • Status changed from In Progress to Resolved
Actions
Copy link
 #9

Updated by krauselukas about 7 years ago

  • Status changed from Resolved to In Progress
Actions
Copy link
 #10

Updated by szarate about 7 years ago

  • Status changed from In Progress to Resolved

Feature tour feature has been implemented, but needs more love in order to be actually useful.

Actions
Copy link
 #11

Updated by mkittler over 6 years ago

The current status regarding the tour is that we need to implement further tours for gathering user feedback.

When trying to create a tour for Customize selection for candidate needles + full diff view to gather some first user feedback feature I noticed some problems:

  • The tour is currently only defined in JavaScript. However, it would be required to access the database from it. Ok, we could use AJAX and our existing rest API to find out a suitable and recent job (where results hopefully haven't been removed yet).
  • When we find a suitable job, we would need to find suitable result screenshots. Since the interesting parts (available candidate needles) are lazy-loaded, the required information is not immediately available to the JavaScript. Hence more AJAX required.
  • Or we implement the concept of 'tour fixtures'. So we can skip the mentioned effort and just run the tour on well known dummy data. That seems like the less error prone approach to me. But also effort to implement.
  • The tour is implemented as a bootstrap popover. This very likely collides with showing a dropdown menu at the same time. At least I expect some extra effort for this to work.

To summarize: I don't think this feature is a good place to start for extending the tour feature. Especially when we're still investigating it and want to collect feedback. It would be much effort and likely we would provide a tour which doesn't work very well due to the complexity.

Note that these problems don't apply to all features we possibly want to show in a tour. The maintenance effort for the tour is also low (we've just migrated to Bootstrap 4). So I would keep the tour and try it out later when we introduce a new feature where it makes more sense.

If we later decide to keep the tour, I would opt for the 'tour fixtures' approach to handle test-data specific features.

Actions
Copy link

Also available in: Atom PDF