Admin interface

[yoe]

SReview is also used for DebConf, which is a full-week conference with a packed schedule, as well as for minidebconfs, which are smaller one- or two-day conferences that usually decide on their schedule in a fairly ad-hoc way. The result is that usually there's no machine-parseable version of the schedule, and so I have to manually start copying titles and speakers etc into

I was thinking that it might be a good idea to add schedule editing features to SReview, so that these smaller events would be able to edit the schedule through the webinterface. This would make things easier for them, and would also make my life a bit less of a hassle when handling an event, since for the small events currently I just copy-paste strings into SQL statements -- which obviously is not an ideal situation.

Ideally, the schedule editing application would also allow to add speakers, and would allow people to move talks around by way of a very strongly mouse-based interface, or some such.

[yoe]

@belenbarrospena, do you have any ideas about this?

[belenbarrospena]

I have 2 thoughts:

Thought number 1 is ... yikes! This is potentially a big feature.

Thought number 2 is that I would need to understand the problem way better before I have any design ideas. If you are serious about this, it may be worth organising a call so that you can explain to me your existing SQL statements workflow.

The other thing that comes to mind is that this is the kind of feature that could easily bleed into other application's territory. I may be wrong, but I don't think you want sreview to become a conference schedule management app. If that's the case, we will probably need to manage the scope of the feature quite carefully.

Sounds interesting though, so happy to put some time into it :)

[yoe]

On Thu, Jun 06, 2019 at 10:49:59AM -0700, Belen Pena wrote:

I have 2 thoughts:

Thought number 1 is ... yikes! This is potentially a big feature.

Heh. Well, only if you go overboard with it, which I don't think is necessary. Then again... well, read on :)

Thought number 2 is that I would need to understand the problem way better before I have any design ideas. If you are serious about this, it may be worth organising a call so that you can explain to me your existing SQL statements workflow.

We can definitely do that. When would that be most convenient for you?

Having given this some more thought though, there's more to this than just "add a schedule editor"; I need to redo the admin interface, so that administrators can use it to review talks that require comments, override talk reviews and talk states and, yes, also edit the schedule. This seems like a good place to start for that, so I don't want to enlarge the scope right now, but you might want to keep that in mind while designing the interface.

The other thing that comes to mind is that this is the kind of feature that could easily bleed into other application's territory. I may be wrong, but I don't think you want sreview to become a conference schedule management app.

No, I don't, indeed. I'm only envisioning using this as a schedule editor for really small conferences like the DebConf Hamburg one that's on now; see the Debian SReview instance:

https://sreview.debian.net/overview

There's not a lot there, and for events that are really small like that, having people manage their schedule in SReview could be sufficient.

If that's the case, we will probably need to manage the scope of the feature quite carefully.

Sounds interesting though, so happy to put some time into it :)

Cool, thanks :-)

-- To the thief who stole my anti-depressants: I hope you're happy

-- seen somewhere on the Internet on a photo of a billboard

[belenbarrospena]

Thought number 2 is that I would need to understand the problem way better before I have any design ideas. If you are serious about this, it may be worth organising a call so that you can explain to me your existing SQL statements workflow. We can definitely do that. When would that be most convenient for you?

I could do over the weekend pretty much any time, or next week from Monday to Wednesday from 17:30 (BST). We could still use Jitsi https://meet.jit.si/sreview

Your comments about the admin interface make sense, and we should definitely keep that in mind when agreeing on design stuff.

From the DebConf schedule it looks like creating / editing a session would involve people providing / editing the following data:

Title Speaker(s) Room Start time End time

Anything missing from that list?

[yoe]

On Fri, Jun 07, 2019 at 02:30:38AM -0700, Belen Pena wrote:

Thought number 2 is that I would need to understand the problem way better before I have any design ideas. If you are serious about this, it may be worth organising a call so that you can explain to me your existing SQL statements workflow. We can definitely do that. When would that be most convenient for you?

I could do over the weekend pretty much any time, or next week from Monday to Wednesday from 17:30 (BST). We could still use Jitsi https://meet.jit.si/sreview

What about tomorrow evening then?

Your comments about the admin interface make sense, and we should definitely keep that in mind when agreeing on design stuff.

From the DebConf schedule it looks like creating / editing a session would involve people providing / editing the following data:

Title Speaker(s) Room Start time End time

Anything missing from that list?

A few optional fields that don't show up on the schedule: subtitle, track, and description. If the same interface is also going to be used during review for managing the talks, then we'd also need active stream, and the ability to override the current state.

Speakers are stored in a separate table and can be reused for other events. The database allows to also store email addresses for speakers (which is required for FOSDEM, otherwise we don't know where to send emails to ;-)

We'll discuss this in detail during the meeting.

--

Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22

[belenbarrospena]

I could do over the weekend pretty much any time, or next week from Monday to Wednesday from 17:30 (BST). We could still use Jitsi https://meet.jit.si/sreview What about tomorrow evening then?

Sounds goods. 19:00 BST?

[yoe]

Perfect. See you then!

[belenbarrospena]

I've pushed a very, very basic first design for editing talks to

https://belenbarrospena.github.io/sreview_design/video_overview.html

The table is very much the way it currently is. I just added an 'edit' icon to the left of each talk title. When you click on it, you go to an 'edit talk' page with a simple form.

https://belenbarrospena.github.io/sreview_design/edit_talk.html

I have lots of questions of course. I'll just list them here so that I don't forget about them (doesn't mean you have to type an answer for each of them):

• How is the current video overview table sorted? By state then time? Should we keep this sorting or should we explore other criteria?
• Should we add sorting options to the table so that users can customise the table sorting?
• Do we need an option to search talks (e.g. by title or speaker)?
• Do we need filters (e.g. by room, by track or by state)?
• Do we need an option to add a talk?
• Do we need the option to delete a talk?
• How likely are small conferences to have more than one room and more than one track? Must the design we choose play nice with big events like FOSDEM, that has dozens of tracks and rooms?

Feedback, as usual, very welcome.

[yoe]

I've pushed a very, very basic first design for editing talks to

https://belenbarrospena.github.io/sreview_design/video_overview.html

That is rather basic, indeed. Will need quite some updates still, I'm afraid (see below).

The table is very much the way it currently is. I just added an 'edit' icon to the left of each talk title. When you click on it, you go to an 'edit talk' page with a simple form.

https://belenbarrospena.github.io/sreview_design/edit_talk.html

I have lots of questions of course. I'll just list them here so that I don't forget about them (doesn't mean you have to type an answer for each of them):

Doesn't hurt either, I guess ;-)

• How is the current video overview table sorted? By state then time? Should we keep this sorting or should we explore other criteria?

• Should we add sorting options to the table so that users can customise the table sorting?

The overview page is ordered by first state, then progress, then room, then time. This is useful for the overview page because it allows users to see their talk move downwards on the page as it progresses through the system, but is of not much use for the admin interface and so should probably not be used there.

Using the ability to sort things on the client side (in javascript) that angular provides is probably a better idea.

For clarity: the overview table is a basic table that will not change. This is meant for users who just want to see the current state of a talk, and nothing more.

We're talking about the admin interface, which can be based off the overview table, but which will not be the same.

• Do we need an option to search talks (e.g. by title or speaker)?

• Do we need filters (e.g. by room, by track or by state)?

Yes, to both. Angular has functionality to implement filters on the client side (i.e., fully in javascript) and can do filter as you type-style substring matching, as well as limiting the visible talks based on a selection in a dropdown list or similar; I definitely want to use that type of functionality, which will be necessary for the larger conferences.

• Do we need an option to add a talk?

• Do we need the option to delete a talk?

Yes, to both. They are the whole point of this exercise ;-)

• How likely are small conferences to have more than one room and more than one track? Must the design we choose play nice with big events like FOSDEM, that has dozens of tracks and rooms?

Very unlikely. However, the design is planned to replace the admin interface; as such, it should indeed play nice with them, since otherwise those big events won't have a workable admin interface anymore ;-)

[belenbarrospena]

I've started to look at the design for the additional functionality in the presentations table: searching, sorting and filtering.

While designing the track filter, I've come across the question of what's a track at FOSDEM. I guess that all the keynotes are a single track, as are all the lightning talks, but then:

• each devroom is a track on its own (e.g. the open source design devroom)
• each main track is also a track on its own (e.g. databases)

Is that correct?

[yoe]

Pretty much, yes; you should think of a track as a grouping of talks that may or may not correlate to a room, and which has a responsible email address assigned to it. The track manager is Cc'd on all the mails that get sent out to speakers. It might be useful at some point to also allow the track manager to log in to the admin interface, and then we could lock the track filter to the track he's responsible for. This is not critical though, and I might decide against it in the end. Needs some thought.Also note that while rooms are required, SReview does not require the use of tracks.

[belenbarrospena]

Here is a video explaining a possible design for the additional functionality needed for the admin interface

https://youtu.be/NNSTwRdPhrI

The clickable prototype is at https://www.figma.com/proto/D4KeBoRVgp8YeQV3bO6FXONY/sreview-admin-interface?node-id=65%3A11&viewport=-1355%2C1850%2C0.6087465286254883&scaling=min-zoom&redirected=1

Let me know what you think

[yoe]

Looks great so far, although there are a few things that jump to mind:

• The number of tracks and rooms depends on the conference. For FOSDEM there are many, but for some other conferences there might only be a handful of each. Should we disable the filtering and scrolling for those if there are less than, say, 5 items in a list?
• The start- and endtimes are specified as TIMESTAMP data types, i.e., they have date and time in them. While I can split that up to present them in separate columns, this would mean that sorting by start time and/or date will be linked together. I don't think that's a problem, but I though I'd mention it.

That seems like the most important bits so far. I'll give it some more thought; if I can think of something else, I'll let you know.

[belenbarrospena]

The number of tracks and rooms depends on the conference. For FOSDEM there are many, but for some other conferences there might only be a handful of each. Should we disable the filtering and scrolling for those if there are less than, say, 5 items in a list?

The scrolling shouldn't be a problem, since if the number of items doesn't cause the container to overflow, then it will not scroll. But yes, in those cases where there are only a few items (5 sounds like a reasonable number) we should hide the search input field in the filter.

The start- and endtimes are specified as TIMESTAMP data types, i.e., they have date and time in them. While I can split that up to present them in separate columns, this would mean that sorting by start time and/or date will be linked together. I don't think that's a problem, but I though I'd mention it.

Yes, you are completely right. Basically, we will break down the timestamps for display purposes only. It just makes for easier reading. But that will mean that sorting by date and sorting by starting time will do exactly the same thing. We have 2 options:

1. We make only one of the columns sortable
2. We make both columns sortable, even though they do the same thing.

I would be happy with any of the 2 options: I think people will get it either way.

Since you seem happy with the approach, I will start designing things in more detail and fidelity.