Preparing the user interface

UX / User Research
#1

@dachary Is there a guide to follow (similarly to) in order to prepare the user interface?

I noted the following steps, I guess some are missing?

  • :red_circle: find volunteers
  • :red_circle: find someone willing to create the UI / a webdesigner
  • :red_circle: find an UX designer to propose a few workflow to be tested with volunteers
  • :red_circle: test a few workflow with volunteers

I noted there are already some volunteers.

DRAFT: monthly report, November 2021
#2

I’ve never done that so I would not know. The steps you mention make sense to me.

#3

This subject was discussed during our lengthy oral meeting.

@dachary highlighted that time will especially constrain what could be done.

I said that:

  • first some context is required; i don’t fully understand the steps above. Which user interface? For which workflow? It was initially planned to avoid any interface (using the interfaces of the existing forges and for example a prefix with the federated issues such as fedeproxy:). Is there an admin user interface?
  • then the steps need to be split into smaller steps, in the same way the first issues were created for the initial fedeproxy repository - it was during a constructive exchange.
  • I agreed that time will constrain the achievable steps and the schedule will reflect that.
#4

I took a look at the deliverables due end of January 2022 because they are listed in the proposal. It reads I3 Create the fedeproxy server user interface. I think it makes sense that the user is a system administrator running fedeproxy alongside a GitLab or Gitea instance. The interface I like to have as a system administrator is a cli, with a configuration file.

This can be achieved by wrapping fedeproxy into a docker image. The options available from the underlying web framework (Django or chi) when running the server are modified to include new options, specific to fedeproxy. The configuration file also has additional options that are only meaningful to fedeproxy.

Once this is complete, or in parallel, it would be good to design a UI that is friendly to the forge users (Gitea or GitLab), but that’s not a required deliverable by January 2022.

#5

The grant proposal states in the user experience activity section:

in the related section, the project full description mentions

One of the recommendations of the user research report is:

Note that the early versions of the grant proposal didn’t include this milestone.

It looks like a way to embed Fedeproxy in the UI of the forges currently in use means: Fedeproxy is integrated/dissolved in these forges. This isn’t an realistic goal for before the end of January 2022 :slight_smile: Instead, using a format recognized by Fedeproxy in the issue titles is achievable (It was something we evoked during an oral discussion).

Did we define the user experience roadmap for interacting with the fedeproxy server in a formal way? We had a lot of spoken exchanges on this subject, isn’t the time to write down the user workflows?

Returning to the milestone, the remaining implementable user interface is the admin one, a cli and/or a configuration file would fit. About the schedule of this milestone, this cli and/or configuration file will be an outcome of the future developments.

#6

Not that I remember.

Agreed.

#7

I am not sure why it wasn’t done. Should not this be done before any further development?

#8

Yes, that would make sense.

#9

I described the functional workflows we talk about and then I only kept the parts where the users are involved.

Some mechanisms are not clear, updates will be required. Once refined, i will use a version control friendly text format, for example the DOT language.

#10

@misc mentioned a useful use case: one project (or one user?) follows a dependency project hosted on another forge and there is a notification (a new issue could be created) when a new release of the dependency is created.