Admin interface #71
Comments
|
@belenbarrospena, do you have any ideas about this? |
|
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 :) |
|
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
|
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 Anything missing from that list? |
|
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.
…--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
|
Sounds goods. 19:00 BST? |
|
Perfect. See you then!
|
See yoe/SReview#71 Signed-off-by: Belen Pena <[email protected]>
|
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):
Feedback, as usual, very welcome. |
That is rather basic, indeed. Will need quite some updates still, I'm afraid (see below).
Doesn't hurt either, I guess ;-)
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.
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.
Yes, to both. They are the whole point of this exercise ;-)
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 ;-) |
|
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:
Is that correct? |
|
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.
|
|
Here is a video explaining a possible design for the additional functionality needed for the admin interface The clickable prototype is at Let me know what you think |
|
Looks great so far, although there are a few things that jump to mind:
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. |
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.
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:
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. |
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.
The text was updated successfully, but these errors were encountered: