Re: [Tools-discuss] Early preview of upcoming changes to the agenda pages

[Nick <[e-mail]>]

1) The current version on the sandbox environment only supports large
screens with a fully expanded browser window.
Smaller screens, tablet and mobile sizes are still being worked on.

The goal is to have a dynamic layout that makes sense depending on your
screen size, while still having access to all features.
For example, on mobile, there will be floating buttons at the bottom of the
screen to access the various features.

2) For what information to display, it will be customizable per user via a
new "Agenda Settings" panel (see preview
https://1drv.ms/u/s!AuiTIfpc1Mn7hPMuXIy8jS6LjFvj7w?e=pVmmvn). If floor /
group area lozenges are not relevant to you, you can hide them.
Your settings will persist across meetings via your browser localStorage.
The only exception is the agenda note which will be turned back on if the
contents change.

3) As for selectable colors, they would be customizable via the "Agenda
Settings" panel (see screenshot linked above) and can be named to anything
you want (e.g. Important, Interesting, etc.). These colors/tags can then be
assigned to individual sessions in the list. The custom colors / names you
choose would also persist across meetings.

4) The "Now" link in the "Jump To..." section only appears while the
meeting is taking place, hence why it's not displayed right now. Same for
the red line which travels across the list in real time.

5) Some bugs like the time / icons incorrectly showing on 2 lines, or the
non-session events not aligning have been fixed but are not yet deployed on
the sandbox environment.

Thanks for all the feedback so far!

Nick

On Tue, 21 Jun 2022 at 13:59, John C Klensin <[e-mail]> wrote:

> Robert,
>
> Observations that (mostly) have not been raised by others:
>
> (1) Please rethink screen real estate.  Especially for those who
> want or need to run browsers at less than full screen and for
> those who use screens at lower resolution (or higher
> magnification) than you expect (see Cindy's note, but the
> problem is more general), that rather wide navigation column to
> the right is wasting space that could be better used in other
> ways -- keeping the actual agenda displays to one line per
> meeting in almost all cases, using slightly larger characters
> for those lines, etc.  I note that, if I narrow the browser
> window enough, that column disappears entirely, so you obviously
> do not consider it essential.  Making it half the width when it
> shows or giving the option of turning it off entirely even in
> full-screen view and making the session names a bit larger
> probably would be a good tradeoff.  For the vertical version of
> the same issue, keeping the row of icons starting with "Show
> meeting materials" as one row rather than wrapping them with a
> narrower frame would help.  It would also make it easier to see
> all of the meetings for a given time slot without scrolling and,
> for someone trying to use a touch screen with fingers or a
> stylus, sticking with one row and larger type for the meeting
> name (either making the icons bigger or leaving more vertical
> space between rows) would probably make things more usable. You
> might even consider narrowing the left column even if it meant
> stacking starting and ending times.
>
> >From one point of view, the adaptability of the display --e.g.,
> things coming and going based on frame height or width -- is
> really clever and elegant.  On the other hand, as Tero pointed
> out, it can be very confusing.  As a way to get a handle on the
> tradeoffs, think about how you would explain how to use that
> page and where find things on it in writing or to someone remote.
>
>
> (2) The plaintext version of the agenda is important to at least
> some of us.  Some have specialized tools that don't work on the
> web pages.  Plaintext may be the framework of a good way to take
> notes on the meeting rather than on individual sessions.  There
> are circumstances in which its compactness or the ability to
> load it much more quickly than a complete web page may be
> important.  And so on.   Especially as the web version becomes
> more complex in terms of layout and adjustments to the local
> environment (as discussed above and by others), it would be
> helpful to be able to do an early review of what the plaintext
> version will look like rather than, e.g., assuming that a
> mapping from the web version will just work out and produce
> something reasonable.  Some of the reasons above also suggest
> that the plaintext version be stored on the server in that form
> and updated only when substantive changes are made to the web
> version, rather than being generated dynamically.  Even if that
> means it might lag for some hours, that might be a good tradeoff.
>
> (3) In addition to issues raised by others about the Area
> lozenges (I do believe information about the Area associated
> with a given group is useful, just not that particular display
> form), it is not clear what the icons /picture language on
> non-area lines mean or what important information they provide.
> If those symbols are useful, it is far more important that they
> be accompanied by a glossary or tool tips than the Areas because
> they are less familiar to the community.  By contrast, tooltip
> popups for each Area name are probably less useful: for an IETF
> participant, even a newcomer, who does not know what the areas
> are about, either they don't need to know or the information
> provided may not be enough.   On the other hand, if they don't
> know what the Area abbreviations mean, how do we expect them to
> figure out whether "INT AD Office Hours" and similar slots mean,
> much less how many participants will instantly made the right
> association/ translation for "RPC", "ISE", "IPEG", and maybe
> even "IANA".   Let's try to at least be consistent about
> supplying expansions of possibly-unfamiliar terms or links to
> where explanations can be found.  If we assume the reader will
> know those terms, then please avoid the clutter.
>
> (4) Finally, let me point out again that this list and the
> people on it are probably not representative of the collection
> of people whom we expect or hope will participate in an IETF
> meeting.  It would be helpful to permit and encourage a wider
> review of the preview (perhaps at a more mature stage) or at
> least to announce to the broader community that the review is
> going on, ideally without requiring that they join this list and
> have to watch its discussions of other topics.
>
> thanks,
>    john
>
>
> --On Wednesday, June 15, 2022 17:00 -0500 Robert Sparks
> <[e-mail]> wrote:
>
> > All -
> >
> > The code that generates the agenda pages has been iteratively
> > changed over many meetings and it has grown to the point that
> > it is very difficult to maintain.
> >
> > We have a re-implementation in progress that assumes a
> > different way of rendering the agendas from the outset. It has
> > the browser doing most of the work. At the moment, it
> > front-loads all of the data that drives it before showing
> > anything, so the initial load is still quite long, but that
> > will change to fetching data as it's needed as we go forward.
> >
> > We've deployed the current version at the sandbox - please
> > take some time to play around at
> > https://sandbox.ietf.org/meeting/113/agenda and send feedback
> > to this list, or directly to nick or me (addresses in the
> > headers). In particular, let us know if something looks broken
> > or if the new approach is missing something that you have
> > relied on.
> >
> > We currently expect to finish the re-implementation and merge
> > this into production before IETF 114.
>
>
>