You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by "John D. Ament" <jo...@apache.org> on 2017/06/23 02:40:12 UTC
Roster tool UX - Option 1
Hey guys
I finally got time to write down in confluence the first sketch put
together for the new roster tool. You can find it here:
https://cwiki.apache.org/confluence/display/WHIMSICAL/Roster+Tool+Option+1
A few notes of what went into this:
- I demoed the IPMC roster page
- I demoed the phonebook
- I showed a "day in the life of" where I demoed how Trevor Grant was added
to the incubator committers, Steve Blackmon to the IPMC.
the identified pieces missing included:
- How to find existing committers
- How to add someone new
- How to change someone existing's roles
- How to make bulk changes
The a-ha moment came when I showed bulk how bulk changes work right now.
The main points are that someones role should be represented as a combo box
(especially since PMC/PPMC implies committer) to chose which level someone
is (from a list of options). Add should append a new row to the table, and
you do searches from there, an autocomplete component ala
https://jqueryui.com/autocomplete/ was suggested . Once someone has been
added in some way, the username column is not editable. Removing someone
is ambiguous. We don't do it much, so either there's an option in the
combo box for "emeritus" or a delete icon on the right. I'm inclined to
say emeritus to better match our policies, but I'm not sure we track that
info right now. The table should include everyone, not separate tables per
role. It becomes hard to find people. The inline search should just do a
basic text match against the row. E.g. if I type in committer it should
show all committers. Moving save outside reinforces the bulk operation
feel. Instead of making single changes you're always making multiple
changes at once.
Thoughts?
John
Re: Roster tool UX - global whimsy styles
Posted by sebb <se...@gmail.com>.
On 29 June 2017 at 13:58, Shane Curcuru <as...@shanecurcuru.org> wrote:
> Separately from how we display editable data, I'd like to use consistent
> bootstrap styles for the overall roster pages: navbar/footer, and using
> panels and/or bootstrap default table settings where possible.
>
> https://github.com/apache/whimsy/commit/73949887ad8dc7b767ba6ff0e40875199df395a5
>
> The roster-style branch does this for the /roster landing page, and for
> the /roster/members listing page. Issues/Questions:
>
> - To apply whimsy&bootstrap styles throughout, much of the app.css file
> will go away, since we'll be using default bootstrap styles. That's why
> the table separator lines run outside to the right of the panels on
> /roster/members in this example. Thus I'd like feedback on if this kind
> of display is good before working through the rest of the roster html.
>
> - For super-simple pages, I was going to leave small tables as-is, like
> on /roster.
>
> - For most pages, I propose wrapping tables in a _whimsy_panel_table, so
> that we can provide a sentence of description for what the table is.
>
> - Since different parts of the roster tool are member-private,
> committer-private, or public, I think it's important to start
> documenting this in the pages. Hence the glyphicon_lock as a hint in
> the explanatory text at the top of some tables.
>
> - Haven't yet figured out why the stupidtable doesn't sort the Member
> Listing table.
>
> - Adding these styles can go forward separately from the "how to display
> editable" work - although if we have a specific bootstrap style or
> metaphor we want to wrap editable tables vs. read-only tables, now's the
> time to discuss.
>
> That is: one potential hint to users would be to wrap the Member or
> Committer listing pages (read-only) in a certain color bootstrap
> panel-primary, and wrap potentially editable listing pages like PMC
> rosters in a different color panel-info or panel-success.
>
>
> Comments?
[This is somewhat tangential, but needs to be considered in
conjunction with other markings:]
For large PMCs, it can be difficult to tell if a person is in the
committee group or the unix group without careful scrolling.
In particular, Incubator.
It would be useful to be able to add a background to show which is which.
> - Shane
>
>
>
>
> --
>
> - Shane
> https://www.apache.org/foundation/marks/resources
Re: Roster tool UX - global whimsy styles
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Separately from how we display editable data, I'd like to use consistent
bootstrap styles for the overall roster pages: navbar/footer, and using
panels and/or bootstrap default table settings where possible.
https://github.com/apache/whimsy/commit/73949887ad8dc7b767ba6ff0e40875199df395a5
The roster-style branch does this for the /roster landing page, and for
the /roster/members listing page. Issues/Questions:
- To apply whimsy&bootstrap styles throughout, much of the app.css file
will go away, since we'll be using default bootstrap styles. That's why
the table separator lines run outside to the right of the panels on
/roster/members in this example. Thus I'd like feedback on if this kind
of display is good before working through the rest of the roster html.
- For super-simple pages, I was going to leave small tables as-is, like
on /roster.
- For most pages, I propose wrapping tables in a _whimsy_panel_table, so
that we can provide a sentence of description for what the table is.
- Since different parts of the roster tool are member-private,
committer-private, or public, I think it's important to start
documenting this in the pages. Hence the glyphicon_lock as a hint in
the explanatory text at the top of some tables.
- Haven't yet figured out why the stupidtable doesn't sort the Member
Listing table.
- Adding these styles can go forward separately from the "how to display
editable" work - although if we have a specific bootstrap style or
metaphor we want to wrap editable tables vs. read-only tables, now's the
time to discuss.
That is: one potential hint to users would be to wrap the Member or
Committer listing pages (read-only) in a certain color bootstrap
panel-primary, and wrap potentially editable listing pages like PMC
rosters in a different color panel-info or panel-success.
Comments?
- Shane
--
- Shane
https://www.apache.org/foundation/marks/resources
Re: Roster tool UX - Option 1
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jul 8, 2017 at 8:14 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> Possible example to emulate?
>
> https://editor.datatables.net/examples/styling/bootstrap
I've made a number of changes, for the moment only to the PMC pages
(i.e., not to the PPMC pages), borrowing ideas from a number of
sources, including the link above.
I've added a search bar. Entering text in there will filter the
results. Note: because the results combine committers and PMC
members, functionality is lost. The combined list won't show dates
added to the PMC, won't show issues like differences between LDAP and
committee-info.txt, won't show PMC members who aren't committers, etc.
It also won't provide buttons to correct these issues.
I've added add and modify buttons, which will only show up if the user
is authorized to modify the roster being viewed. There also are
checkboxes in front of each row allowing the selection of users to be
modified.
I've removed the rows containing + signs. I've removed the
explanatory box at the top. I've removed the ability to double click
on a row to see actions.
I added the ability to click on the last column to expose actions.
I've also changed the cursor to a pointer when hovering over issues
that show in this column. The idea is that if you see an issue, you
can click on it to show actions that can be used to resolve this
issue.
These changes aren't necessarily meant to be final, but once stable,
I'll port the results to the PPMC roster pages.
- Sam Ruby
Re: Roster tool UX - Option 1
Posted by Sam Ruby <ru...@intertwingly.net>.
Possible example to emulate?
https://editor.datatables.net/examples/styling/bootstrap
- Sam Ruby
Re: Roster tool UX - Option 1
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Jun 28, 2017 at 5:25 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> John D. Ament wrote on 6/28/17 6:28 AM:
>> On Fri, Jun 23, 2017 at 8:53 AM Sam Ruby <ru...@intertwingly.net> wrote:
>>
>>> On Fri, Jun 23, 2017 at 7:54 AM, Shane Curcuru <as...@shanecurcuru.org>
>>> wrote:
> ...snip...
>
>>> 2) replace the dropdown with a pencil icon, and have clicking on that
>>> create a dialog box that walks you through the potential operations.
>>>
>>
>> I guess the question is whether or not I'm coming in and it's already
>> editable. A dialog breaks the flow, especially since you're not changing a
>> lot of details about a user. Their name should be coming from LDAP, so its
>> literally the contents of the drop down.
>
> That's the big question: how do we clearly keep editing operations
> simple and straightforward, but ensure that users understand when they
> do X (click Submit, select name from combobox, whatever) that it will
> actually write that operation. Dialog boxes make this implicitly clear,
> but I agree break the flow. I just want to be sure that whatever
> metaphor we have for "Make this change now" is consistent.
FWIW, my original thought process was that different tools may have
different target audiences.
The board agenda tool, for example, has a small number of people who
use it each and every month. Such users may indeed wish to invest a
small amount of time in learning the tool as they will be using it
frequently.
The roster tool is different. There may be an initial load, there may
be a few users who use it frequently, but most users will use it not
only infrequently, but there may be long and unpredictable periods of
time between usages.
As such, I feel that editing operations in the roster tool would
benefit from a more guided approach:
https://en.wikipedia.org/wiki/Wizard_(software)
- Sam Ruby
Re: Roster tool UX - Option 1
Posted by Shane Curcuru <as...@shanecurcuru.org>.
John D. Ament wrote on 6/28/17 6:28 AM:
> On Fri, Jun 23, 2017 at 8:53 AM Sam Ruby <ru...@intertwingly.net> wrote:
>
>> On Fri, Jun 23, 2017 at 7:54 AM, Shane Curcuru <as...@shanecurcuru.org>
>> wrote:
...snip...
>> 2) replace the dropdown with a pencil icon, and have clicking on that
>> create a dialog box that walks you through the potential operations.
>>
>
> I guess the question is whether or not I'm coming in and it's already
> editable. A dialog breaks the flow, especially since you're not changing a
> lot of details about a user. Their name should be coming from LDAP, so its
> literally the contents of the drop down.
That's the big question: how do we clearly keep editing operations
simple and straightforward, but ensure that users understand when they
do X (click Submit, select name from combobox, whatever) that it will
actually write that operation. Dialog boxes make this implicitly clear,
but I agree break the flow. I just want to be sure that whatever
metaphor we have for "Make this change now" is consistent.
...snip...
>>>> - How to find existing committers
>>>
>>> The search box isn't completely clear to me: if you're just finding
>>> committers within a PMC, how is this faster than CTRL-F to use the
>>> browser search?
>>
>
> The search box should be limiting the displayed users to only those who
> match. There may be multiple matches. Browser based search doesn't have
> all of those features. It also wouldn't be able to match in a drop down
> box.
Good point, that is definitely valuable.
...snip...
>>> No, please do not use emeritus. While some PMCs use it as a social
>>> convention, from the board's point of view, individuals are either on a
>>> PMC or not on the PMC - there is no other state.
>>
>
> That's fine, as long as all the chairs agree as well.
Let me rephrase. Immaterial of what some PMCs may think, the ASF either
considers an individual to be on a PMC, or not on the PMC. There is no
emeritus state within projects as far as the *Foundation* is concerned.
So any UI needs to clearly track in PMC / not in PMC, which is what ends
up being reflected in committee-info.txt or LDAP.
*If* someone wants to build UI and another per-PMC storage location to
list emeritus members from that PMC, that's fine. But the core UI needs
to first handle add/delete operations (and hopefully handling the 72
hour NAK period intelligently).
...snip...
--
- Shane
https://www.apache.org/foundation/marks/resources
Re: Roster tool UX - Option 1
Posted by "John D. Ament" <jo...@apache.org>.
On Fri, Jun 23, 2017 at 8:53 AM Sam Ruby <ru...@intertwingly.net> wrote:
> On Fri, Jun 23, 2017 at 7:54 AM, Shane Curcuru <as...@shanecurcuru.org>
> wrote:
> > Separately: we should include a short help text that defines who's
> > supposed to be able to do add/delete/change operations, along with links
> > to the specific PMC how to documentation. Especially if we end up with
> > an auth where members could technically do things that socially they
> > shouldn't (i.e. for PMCs they're not on).
> >
> > John D. Ament wrote on 6/22/17 10:40 PM:
> >> Hey guys
> >>
> >> I finally got time to write down in confluence the first sketch put
> >> together for the new roster tool. You can find it here:
> >>
> https://cwiki.apache.org/confluence/display/WHIMSICAL/Roster+Tool+Option+1
> >
> > +1 chair's row should be edit-only. If we get fancy, include a ? button
> > in place of any edit button that links to the "how to change PMC chair
> > resolution" page.
> >
> > +1 to somehow including an "x" delete button; PMCs need to be able to do
> > that operation as well.
>
> I see the 'dropdown' as the way to change an existing person's status.
> Perhaps:
>
> 1) emeritize/delete can be an option there. FWIWI share Shane's
> comment below about not using emeritze.
>
I have mixed feelings about emeritus. I'm fine if we just want a delete
button. Others seem to value emeritus heavily.
>
> 2) replace the dropdown with a pencil icon, and have clicking on that
> create a dialog box that walks you through the potential operations.
>
I guess the question is whether or not I'm coming in and it's already
editable. A dialog breaks the flow, especially since you're not changing a
lot of details about a user. Their name should be coming from LDAP, so its
literally the contents of the drop down.
>
> >> A few notes of what went into this:
> >>
> >> - I demoed the IPMC roster page
> >> - I demoed the phonebook
> >> - I showed a "day in the life of" where I demoed how Trevor Grant was
> added
> >> to the incubator committers, Steve Blackmon to the IPMC.
> >
> > Where/who did you demo with? 8-)
>
Locally, to a buddy of mine who does UX type stuff regularly.
> >
> >> the identified pieces missing included:
> >>
> >> - How to find existing committers
> >
> > The search box isn't completely clear to me: if you're just finding
> > committers within a PMC, how is this faster than CTRL-F to use the
> > browser search?
>
The search box should be limiting the displayed users to only those who
match. There may be multiple matches. Browser based search doesn't have
all of those features. It also wouldn't be able to match in a drop down
box.
> >
> > *If* someone wants to integrate that into the table itself, so it
> > intelligently highlights/re-sorts the table in place to show you
> > matching entries, that would be super-cool, but a lot more work than we
> > really need for something functional.
>
> /me likes this kind of work.
>
Agreed. IMHO, it's worth the effort, but like I always say let's
prioritize the critical pieces.
>
> I often times see whimsy as a "hold my beer" type of project.
> Somebody wants to have a podlingnamesearch indicator on establish
> resolutions in the board agenda: lets do it!
>
> >> - How to add someone new
> >> - How to change someone existing's roles
> >
> > I definitely like a single table with a new column showing
> > (P)PMC/committer status; much simpler to display and look through.
> > Columns do need to be sortable though.
>
> I agree that columns need to be sortable. Without this, the proposed
> design makes it harder to answer questions like "who are the mentors
> of this PPMC"?
>
For a podling, I would imagine the sort order is Mentor -> PPMC ->
Committer. For a TLP, I would imagine its Chair -> PMC -> Committer. With
each of those categories having their contents sorted by name.
The external search helps handle the column based search, but it could be
another way to do the searching, that would just be single column vs
multicolumn.
Granted, it could all be as simple as bringing in something like this:
http://js-grid.com/demos/
>
> >> - How to make bulk changes
> >>
> >> The a-ha moment came when I showed bulk how bulk changes work right now.
> >> The main points are that someones role should be represented as a combo
> box
> >> (especially since PMC/PPMC implies committer) to chose which level
> someone
> >> is (from a list of options).
> >
> > +1, adding someone with check/combo into what role(s) is great.
> >
> >> Add should append a new row to the table, and
> >> you do searches from there, an autocomplete component ala
> >> https://jqueryui.com/autocomplete/ was suggested . Once someone has
> been
> >> added in some way, the username column is not editable. Removing
> someone
> >> is ambiguous. We don't do it much, so either there's an option in the
> >> combo box for "emeritus" or a delete icon on the right. I'm inclined to
> >> say emeritus to better match our policies, but I'm not sure we track
> that
> >> info right now.
> >
> > No, please do not use emeritus. While some PMCs use it as a social
> > convention, from the board's point of view, individuals are either on a
> > PMC or not on the PMC - there is no other state.
>
That's fine, as long as all the chairs agree as well.
> >
> >> The table should include everyone, not separate tables per
> >> role. It becomes hard to find people. The inline search should just
> do a
> >> basic text match against the row. E.g. if I type in committer it should
> >> show all committers.
> >
> > Is within-column searching that important if the table is sortable by
> > all columns intelligently? I.e. when you click to sort by
> > PMC/committer, it uses the name as a secondary sort column, making it
> > easier to find names that way.
> >
> >> Moving save outside reinforces the bulk operation
> >> feel. Instead of making single changes you're always making multiple
> >> changes at once.
> >
> > I'd need to see a more detailed example (and run through the concept
> > myself). But I agree: we need to make the action button that submits
> > changes *very* obvious as to what it's saving, so users clearly
> > understand that.
>
> This is the weakest part of the proposed redesign, IMHO. Too many
> people have been exposed to things like google spreadsheets where you
> make a change and there is no need to do a separate save operation.
> Placing a save button at the bottom of a potentially long list is not
> sufficient. People will make changes, think that they are done, and
> close the browser window.
>
How long of a list are you expecting? TBH, I was expecting some form of
pagination so that you're only going through maybe 10-20 rows at a time.
>
> My suggestion is to focus only on optimizing the bulk add operation,
> and make all of the other operations take effect immediately (though
> generally after a confirmation). Having an add button at the top take
> you to a dialog where you can select multiple people, select a single
> role, and add them all at once would be what I suggest.
>
Dialogs (I'm assuming modals?) tend to break the flow of work. If that
immediately saves that's fine, but then I get into confusing states where I
have some changes local + the modal, what gets saved?
>
> >> Thoughts?
> >>
> >> John
> >
> > --
> >
> > - Shane
> > https://www.apache.org/foundation/marks/resources
>
> - Sam Ruby
>
Re: Roster tool UX - Option 1
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Jun 23, 2017 at 7:54 AM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> Separately: we should include a short help text that defines who's
> supposed to be able to do add/delete/change operations, along with links
> to the specific PMC how to documentation. Especially if we end up with
> an auth where members could technically do things that socially they
> shouldn't (i.e. for PMCs they're not on).
>
> John D. Ament wrote on 6/22/17 10:40 PM:
>> Hey guys
>>
>> I finally got time to write down in confluence the first sketch put
>> together for the new roster tool. You can find it here:
>> https://cwiki.apache.org/confluence/display/WHIMSICAL/Roster+Tool+Option+1
>
> +1 chair's row should be edit-only. If we get fancy, include a ? button
> in place of any edit button that links to the "how to change PMC chair
> resolution" page.
>
> +1 to somehow including an "x" delete button; PMCs need to be able to do
> that operation as well.
I see the 'dropdown' as the way to change an existing person's status. Perhaps:
1) emeritize/delete can be an option there. FWIWI share Shane's
comment below about not using emeritze.
2) replace the dropdown with a pencil icon, and have clicking on that
create a dialog box that walks you through the potential operations.
>> A few notes of what went into this:
>>
>> - I demoed the IPMC roster page
>> - I demoed the phonebook
>> - I showed a "day in the life of" where I demoed how Trevor Grant was added
>> to the incubator committers, Steve Blackmon to the IPMC.
>
> Where/who did you demo with? 8-)
>
>> the identified pieces missing included:
>>
>> - How to find existing committers
>
> The search box isn't completely clear to me: if you're just finding
> committers within a PMC, how is this faster than CTRL-F to use the
> browser search?
>
> *If* someone wants to integrate that into the table itself, so it
> intelligently highlights/re-sorts the table in place to show you
> matching entries, that would be super-cool, but a lot more work than we
> really need for something functional.
/me likes this kind of work.
I often times see whimsy as a "hold my beer" type of project.
Somebody wants to have a podlingnamesearch indicator on establish
resolutions in the board agenda: lets do it!
>> - How to add someone new
>> - How to change someone existing's roles
>
> I definitely like a single table with a new column showing
> (P)PMC/committer status; much simpler to display and look through.
> Columns do need to be sortable though.
I agree that columns need to be sortable. Without this, the proposed
design makes it harder to answer questions like "who are the mentors
of this PPMC"?
>> - How to make bulk changes
>>
>> The a-ha moment came when I showed bulk how bulk changes work right now.
>> The main points are that someones role should be represented as a combo box
>> (especially since PMC/PPMC implies committer) to chose which level someone
>> is (from a list of options).
>
> +1, adding someone with check/combo into what role(s) is great.
>
>> Add should append a new row to the table, and
>> you do searches from there, an autocomplete component ala
>> https://jqueryui.com/autocomplete/ was suggested . Once someone has been
>> added in some way, the username column is not editable. Removing someone
>> is ambiguous. We don't do it much, so either there's an option in the
>> combo box for "emeritus" or a delete icon on the right. I'm inclined to
>> say emeritus to better match our policies, but I'm not sure we track that
>> info right now.
>
> No, please do not use emeritus. While some PMCs use it as a social
> convention, from the board's point of view, individuals are either on a
> PMC or not on the PMC - there is no other state.
>
>> The table should include everyone, not separate tables per
>> role. It becomes hard to find people. The inline search should just do a
>> basic text match against the row. E.g. if I type in committer it should
>> show all committers.
>
> Is within-column searching that important if the table is sortable by
> all columns intelligently? I.e. when you click to sort by
> PMC/committer, it uses the name as a secondary sort column, making it
> easier to find names that way.
>
>> Moving save outside reinforces the bulk operation
>> feel. Instead of making single changes you're always making multiple
>> changes at once.
>
> I'd need to see a more detailed example (and run through the concept
> myself). But I agree: we need to make the action button that submits
> changes *very* obvious as to what it's saving, so users clearly
> understand that.
This is the weakest part of the proposed redesign, IMHO. Too many
people have been exposed to things like google spreadsheets where you
make a change and there is no need to do a separate save operation.
Placing a save button at the bottom of a potentially long list is not
sufficient. People will make changes, think that they are done, and
close the browser window.
My suggestion is to focus only on optimizing the bulk add operation,
and make all of the other operations take effect immediately (though
generally after a confirmation). Having an add button at the top take
you to a dialog where you can select multiple people, select a single
role, and add them all at once would be what I suggest.
>> Thoughts?
>>
>> John
>
> --
>
> - Shane
> https://www.apache.org/foundation/marks/resources
- Sam Ruby
Re: Roster tool UX - Option 1
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Separately: we should include a short help text that defines who's
supposed to be able to do add/delete/change operations, along with links
to the specific PMC how to documentation. Especially if we end up with
an auth where members could technically do things that socially they
shouldn't (i.e. for PMCs they're not on).
John D. Ament wrote on 6/22/17 10:40 PM:
> Hey guys
>
> I finally got time to write down in confluence the first sketch put
> together for the new roster tool. You can find it here:
> https://cwiki.apache.org/confluence/display/WHIMSICAL/Roster+Tool+Option+1
+1 chair's row should be edit-only. If we get fancy, include a ? button
in place of any edit button that links to the "how to change PMC chair
resolution" page.
+1 to somehow including an "x" delete button; PMCs need to be able to do
that operation as well.
>
> A few notes of what went into this:
>
> - I demoed the IPMC roster page
> - I demoed the phonebook
> - I showed a "day in the life of" where I demoed how Trevor Grant was added
> to the incubator committers, Steve Blackmon to the IPMC.
Where/who did you demo with? 8-)
> the identified pieces missing included:
>
> - How to find existing committers
The search box isn't completely clear to me: if you're just finding
committers within a PMC, how is this faster than CTRL-F to use the
browser search?
*If* someone wants to integrate that into the table itself, so it
intelligently highlights/re-sorts the table in place to show you
matching entries, that would be super-cool, but a lot more work than we
really need for something functional.
> - How to add someone new
> - How to change someone existing's roles
I definitely like a single table with a new column showing
(P)PMC/committer status; much simpler to display and look through.
Columns do need to be sortable though.
> - How to make bulk changes
>
> The a-ha moment came when I showed bulk how bulk changes work right now.
> The main points are that someones role should be represented as a combo box
> (especially since PMC/PPMC implies committer) to chose which level someone
> is (from a list of options).
+1, adding someone with check/combo into what role(s) is great.
> Add should append a new row to the table, and
> you do searches from there, an autocomplete component ala
> https://jqueryui.com/autocomplete/ was suggested . Once someone has been
> added in some way, the username column is not editable. Removing someone
> is ambiguous. We don't do it much, so either there's an option in the
> combo box for "emeritus" or a delete icon on the right. I'm inclined to
> say emeritus to better match our policies, but I'm not sure we track that
> info right now.
No, please do not use emeritus. While some PMCs use it as a social
convention, from the board's point of view, individuals are either on a
PMC or not on the PMC - there is no other state.
> The table should include everyone, not separate tables per
> role. It becomes hard to find people. The inline search should just do a
> basic text match against the row. E.g. if I type in committer it should
> show all committers.
Is within-column searching that important if the table is sortable by
all columns intelligently? I.e. when you click to sort by
PMC/committer, it uses the name as a secondary sort column, making it
easier to find names that way.
> Moving save outside reinforces the bulk operation
> feel. Instead of making single changes you're always making multiple
> changes at once.
I'd need to see a more detailed example (and run through the concept
myself). But I agree: we need to make the action button that submits
changes *very* obvious as to what it's saving, so users clearly
understand that.
>
> Thoughts?
>
> John
>
--
- Shane
https://www.apache.org/foundation/marks/resources