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

[John C Klensin <[e-mail]>]

Nick,

This is all good news -- glad you are ahead of us on most of the
comments.  

Suggestions:

(i) Please make those local settings (including "Agenda
Settings" and colors and tags, but not necessarily limited to
them) exportable, preferably in a form that can easily be edited
like name:value or even XML and not some binary form.   Some, I
suspect many, of us use multiple computers with the most common
case being something with a large monitor or more than one at
home or an office and a laptop for travel.  If, as it sounds
like may be the case, there are going to be a lot of settings,
being able to get preferences right without setting up each
machine separately from scratch would be very desirable.

(ii) Watch granularity of those settings very carefully.  For
example, someone might reasonably want to keep the Area
information (which has been there for many years) but not be
distracted by the lozenges and associated pop-ups.   FWIW, I
tried looking at the preview to see if it would give me some
hints about how you are thinking about that, but it appears to
confirm my concern.  E.g., if I turn "Display Group Area
Indicators" off, will that eliminate the areas associated with
each WG or only the lozenge and pop-up?  It is also not clear
how I set a color for a particular meeting line.  Some sort of
pull-down that I get by right-clicking a line?  Drag and drop?
Or something else?  

(iii) One lesson I draw from the discussions of the last several
days is that, given different personal abilities, preferences,
and habits, what "makes sense" may depend on the user, not just
on aspects of the device such as what you can determine about,
e.g., screen size.  By all means, try to find defaults that
makes sense, but providing for user overrides is still a good
idea.

(iv) For the future (and this may be advice to Robert more than
yourself), it would be helpful if the preview
announcement/request said things like "test this only full
screen on a desktop or laptop with a large screen because
various other configurations are still in progress".  It seems
to be that several of us have wasted considerable time and
energy on issues related to other setups that are not relevant.

thanks again,
   john


--On Tuesday, June 21, 2022 15:43 -0400 Nick
<[e-mail]> wrote:

> 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.
>> 
>> 
>>