How do we find consensus on interface changes?
Do we need a procedure for getting consensus on Koha interface changes? I'm thinking about this issue in part because of a couple of interface changes I've been working on. One for Bug 16421: Move hold edit actions into dropdown menu https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51111) ...and another for Bug 11375: Patron permission names are untranslatable https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11375 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51847) When proposing a change like that should there be a more inclusive process than getting one sign-off and one QA approval? If so, how do we decide what kind of changes require wider approval? How do we solicit opinions from a wider audience? Or is the process working well as-is? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Owen, You bring up a good question? Could the new features which you are proposing be optional? I know that having the features optional would just "kick the can" on interface consensus down the road until the next interface design surfaces. -- Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Tue, May 31, 2016 at 12:30 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Do we need a procedure for getting consensus on Koha interface changes?
I'm thinking about this issue in part because of a couple of interface changes I've been working on. One for Bug 16421:
Move hold edit actions into dropdown menu https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51111)
...and another for Bug 11375:
Patron permission names are untranslatable https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11375 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51847)
When proposing a change like that should there be a more inclusive process than getting one sign-off and one QA approval? If so, how do we decide what kind of changes require wider approval? How do we solicit opinions from a wider audience?
Or is the process working well as-is?
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Could the new features which you are proposing be optional?
They're not really new features, they're just changes to the way existing features look. We can't build options for every change we want to make to the interface. We need to make educated choices about what we think is the best way for things to work. We may not always get it right, but it's our job to make the choice. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Owen, I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings? My $0.02 worth, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Could the new features which you are proposing be optional?
They're not really new features, they're just changes to the way existing features look. We can't build options for every change we want to make to the interface. We need to make educated choices about what we think is the best way for things to work. We may not always get it right, but it's our job to make the choice.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all! Kyle Sent from my phone. Please excuse my brevity. On May 31, 2016 3:32 PM, "Christopher Davis" <cgdavis@uintah.utah.gov> wrote:
Owen,
I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings?
My $0.02 worth,
Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary
On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Could the new features which you are proposing be optional?
They're not really new features, they're just changes to the way existing features look. We can't build options for every change we want to make to the interface. We need to make educated choices about what we think is the best way for things to work. We may not always get it right, but it's our job to make the choice.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I would rather have a Interface guideline the same way we have coding guidelines. I'm pretty sure that there are some UX design patterns available somewhere. If we would like to have a rules, I would suggest that something that changes the screenshot used in the user documentation should be approved, especially when it doesn't add features. Eric On 2016-05-31 15:49, Kyle Hall wrote:
I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all!
Kyle
Sent from my phone. Please excuse my brevity.
On May 31, 2016 3:32 PM, "Christopher Davis" <cgdavis@uintah.utah.gov <mailto:cgdavis@uintah.utah.gov>> wrote:
Owen,
I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings?
My $0.02 worth,
Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov <mailto:cgdavis@uintah.utah.gov> (435) 789-0091 ext.261 <tel:%28435%29%20789-0091%20ext.261> uintahlibrary.org <http://uintahlibrary.org> basinlibraries.org <http://basinlibraries.org> facebook.com/uintahcountylibrary <http://facebook.com/uintahcountylibrary> instagram.com/uintahcountylibrary <http://instagram.com/uintahcountylibrary>
On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org <mailto:oleonard@myacpl.org>> wrote: >> Could the new features which you are proposing be optional? > > They're not really new features, they're just changes to the way > existing features look. We can't build options for every change we > want to make to the interface. We need to make educated choices about > what we think is the best way for things to work. We may not always > get it right, but it's our job to make the choice. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Love it! I'd say this is a much better idea! Kyle Sent from my phone. Please excuse my brevity. On May 31, 2016 4:25 PM, "Eric Bégin" <eric.begin@inlibro.com> wrote:
I would rather have a Interface guideline the same way we have coding guidelines.
I'm pretty sure that there are some UX design patterns available somewhere.
If we would like to have a rules, I would suggest that something that changes the screenshot used in the user documentation should be approved, especially when it doesn't add features.
Eric
On 2016-05-31 15:49, Kyle Hall wrote:
I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all!
Kyle
Sent from my phone. Please excuse my brevity. On May 31, 2016 3:32 PM, "Christopher Davis" <cgdavis@uintah.utah.gov> wrote:
Owen,
I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings?
My $0.02 worth,
Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary
On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Could the new features which you are proposing be optional?
They're not really new features, they're just changes to the way existing features look. We can't build options for every change we want to make to the interface. We need to make educated choices about what we think is the best way for things to work. We may not always get it right, but it's our job to make the choice.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I like the idea of having a role like 'GUI manager' and also the idea of having style guidelines for the interfaces. Actually, I think. we already have both of those, as Owen has been working on writing documentation about existing patterns on the wiki. I am not in favor of approving every change that would change the screenshots, as that would make the clean-up work much harder, that Owen, Aleisha and others have done recently. For bigger changes I'd try sending links to screenshots/bug reports to the mailing list to get some opinions - if there is no clear direction, we can still schedule an official discussion/vote at a meeting. Katrin On 31.05.2016 23:54, Kyle Hall wrote:
Love it! I'd say this is a much better idea!
Kyle
Sent from my phone. Please excuse my brevity.
On May 31, 2016 4:25 PM, "Eric Bégin" <eric.begin@inlibro.com <mailto:eric.begin@inlibro.com>> wrote:
I would rather have a Interface guideline the same way we have coding guidelines.
I'm pretty sure that there are some UX design patterns available somewhere.
If we would like to have a rules, I would suggest that something that changes the screenshot used in the user documentation should be approved, especially when it doesn't add features.
Eric
On 2016-05-31 15:49, Kyle Hall wrote:
I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all!
Kyle
Sent from my phone. Please excuse my brevity.
On May 31, 2016 3:32 PM, "Christopher Davis" <cgdavis@uintah.utah.gov <mailto:cgdavis@uintah.utah.gov>> wrote:
Owen,
I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings?
My $0.02 worth,
Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov <mailto:cgdavis@uintah.utah.gov> (435) 789-0091 ext.261 <tel:%28435%29%20789-0091%20ext.261> uintahlibrary.org <http://uintahlibrary.org> basinlibraries.org <http://basinlibraries.org> facebook.com/uintahcountylibrary <http://facebook.com/uintahcountylibrary> instagram.com/uintahcountylibrary <http://instagram.com/uintahcountylibrary>
On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org <mailto:oleonard@myacpl.org>> wrote: >> Could the new features which you are proposing be optional? > > They're not really new features, they're just changes to the way > existing features look. We can't build options for every change we > want to make to the interface. We need to make educated choices about > what we think is the best way for things to work. We may not always > get it right, but it's our job to make the choice. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I think you've summarized everything nicely. If Owen were interested in taking some official mantel I would not be opposed ; ) I think we need to focus on expediency and uniformity primarily. I think we basically have those two things, but they could both be improved. I would be more than happy to work on adding a UI guidelines section to the wiki. For those interested, here is what I've done so far: https://wiki.koha-community.org/wiki/Developers_Handbook It's a bit rough now because it's really guideline-centric, but I think over time it will come into its own quite nicely. Constructive criticism is welcome! Kyle <https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB> http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Tue, May 31, 2016 at 5:26 PM, Katrin <katrin.fischer.83@web.de> wrote:
I like the idea of having a role like 'GUI manager' and also the idea of having style guidelines for the interfaces. Actually, I think. we already have both of those, as Owen has been working on writing documentation about existing patterns on the wiki.
I am not in favor of approving every change that would change the screenshots, as that would make the clean-up work much harder, that Owen, Aleisha and others have done recently. For bigger changes I'd try sending links to screenshots/bug reports to the mailing list to get some opinions - if there is no clear direction, we can still schedule an official discussion/vote at a meeting.
Katrin
On 31.05.2016 23:54, Kyle Hall wrote:
Love it! I'd say this is a much better idea!
Kyle
Sent from my phone. Please excuse my brevity. On May 31, 2016 4:25 PM, "Eric Bégin" <eric.begin@inlibro.com> wrote:
I would rather have a Interface guideline the same way we have coding guidelines.
I'm pretty sure that there are some UX design patterns available somewhere.
If we would like to have a rules, I would suggest that something that changes the screenshot used in the user documentation should be approved, especially when it doesn't add features.
Eric
On 2016-05-31 15:49, Kyle Hall wrote:
I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all!
Kyle
Sent from my phone. Please excuse my brevity. On May 31, 2016 3:32 PM, "Christopher Davis" <cgdavis@uintah.utah.gov> wrote:
Owen,
I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings?
My $0.02 worth,
Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 ext.261 <%28435%29%20789-0091%20ext.261> uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary
On Tue, May 31, 2016 at 1:01 PM, Owen Leonard < <oleonard@myacpl.org> oleonard@myacpl.org> wrote:
Could the new features which you are proposing be optional?
They're not really new features, they're just changes to the way existing features look. We can't build options for every change we want to make to the interface. We need to make educated choices about what we think is the best way for things to work. We may not always get it right, but it's our job to make the choice.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
+1 for 'Style guidelines' and 'GUI manager' Regarding the Wiki: https://wiki.koha-community.org/wiki/Interface_patterns https://wiki.koha-community.org/wiki/Developers_Handbook (1.2 User Interface) Should this be consolidated in one document? Marc Am 01.06.2016 um 02:43 schrieb Kyle Hall:
I think you've summarized everything nicely. If Owen were interested in taking some official mantel I would not be opposed ; )
I think we need to focus on expediency and uniformity primarily. I think we basically have those two things, but they could both be improved. I would be more than happy to work on adding a UI guidelines section to the wiki. For those interested, here is what I've done so far: https://wiki.koha-community.org/wiki/Developers_Handbook
It's a bit rough now because it's really guideline-centric, but I think over time it will come into its own quite nicely. Constructive criticism is welcome!
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )
On Tue, May 31, 2016 at 5:26 PM, Katrin <katrin.fischer.83@web.de <mailto:katrin.fischer.83@web.de>> wrote:
I like the idea of having a role like 'GUI manager' and also the idea of having style guidelines for the interfaces. Actually, I think. we already have both of those, as Owen has been working on writing documentation about existing patterns on the wiki.
I am not in favor of approving every change that would change the screenshots, as that would make the clean-up work much harder, that Owen, Aleisha and others have done recently. For bigger changes I'd try sending links to screenshots/bug reports to the mailing list to get some opinions - if there is no clear direction, we can still schedule an official discussion/vote at a meeting.
Katrin
On 31.05.2016 23:54, Kyle Hall wrote:
Love it! I'd say this is a much better idea!
Kyle
Sent from my phone. Please excuse my brevity.
On May 31, 2016 4:25 PM, "Eric Bégin" <eric.begin@inlibro.com <mailto:eric.begin@inlibro.com>> wrote:
I would rather have a Interface guideline the same way we have coding guidelines.
I'm pretty sure that there are some UX design patterns available somewhere.
If we would like to have a rules, I would suggest that something that changes the screenshot used in the user documentation should be approved, especially when it doesn't add features.
Eric
On 2016-05-31 15:49, Kyle Hall wrote:
I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all!
Kyle
Sent from my phone. Please excuse my brevity.
On May 31, 2016 3:32 PM, "Christopher Davis" <cgdavis@uintah.utah.gov <mailto:cgdavis@uintah.utah.gov>> wrote:
Owen,
I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings?
My $0.02 worth,
Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov <mailto:cgdavis@uintah.utah.gov> (435) 789-0091 ext.261 <tel:%28435%29%20789-0091%20ext.261> uintahlibrary.org <http://uintahlibrary.org> basinlibraries.org <http://basinlibraries.org> facebook.com/uintahcountylibrary <http://facebook.com/uintahcountylibrary> instagram.com/uintahcountylibrary <http://instagram.com/uintahcountylibrary>
On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org <mailto:oleonard@myacpl.org>> wrote: >> Could the new features which you are proposing be optional? > > They're not really new features, they're just changes to the way > existing features look. We can't build options for every change we > want to make to the interface. We need to make educated choices about > what we think is the best way for things to work. We may not always > get it right, but it's our job to make the choice. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
We are getting too much managers here :) ________________________________ Van: koha-devel-bounces@lists.koha-community.org <koha-devel-bounces@lists.koha-community.org> namens Marc Véron <veron@veron.ch> Verzonden: woensdag 1 juni 2016 08:13:30 Aan: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] How do we find consensus on interface changes? +1 for 'Style guidelines' and 'GUI manager' Regarding the Wiki: https://wiki.koha-community.org/wiki/Interface_patterns https://wiki.koha-community.org/wiki/Developers_Handbook (1.2 User Interface) Should this be consolidated in one document? Marc Am 01.06.2016 um 02:43 schrieb Kyle Hall: I think you've summarized everything nicely. If Owen were interested in taking some official mantel I would not be opposed ; ) I think we need to focus on expediency and uniformity primarily. I think we basically have those two things, but they could both be improved. I would be more than happy to work on adding a UI guidelines section to the wiki. For those interested, here is what I've done so far: <https://wiki.koha-community.org/wiki/Developers_Handbook> https://wiki.koha-community.org/wiki/Developers_Handbook It's a bit rough now because it's really guideline-centric, but I think over time it will come into its own quite nicely. Constructive criticism is welcome! Kyle [http://widgets.ch-or.us/badge/convio/cff/4715/2706639]<https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB> http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( <http://www.meadvillelibrary.org> http://www.meadvillelibrary.org ) Crawford County Federated Library System ( <http://www.ccfls.org> http://www.ccfls.org ) On Tue, May 31, 2016 at 5:26 PM, Katrin <katrin.fischer.83@web.de<mailto:katrin.fischer.83@web.de>> wrote: I like the idea of having a role like 'GUI manager' and also the idea of having style guidelines for the interfaces. Actually, I think. we already have both of those, as Owen has been working on writing documentation about existing patterns on the wiki. I am not in favor of approving every change that would change the screenshots, as that would make the clean-up work much harder, that Owen, Aleisha and others have done recently. For bigger changes I'd try sending links to screenshots/bug reports to the mailing list to get some opinions - if there is no clear direction, we can still schedule an official discussion/vote at a meeting. Katrin On 31.05.2016 23:54, Kyle Hall wrote: Love it! I'd say this is a much better idea! Kyle Sent from my phone. Please excuse my brevity. On May 31, 2016 4:25 PM, "Eric Bégin" <eric.begin@inlibro.com<mailto:eric.begin@inlibro.com>> wrote: I would rather have a Interface guideline the same way we have coding guidelines. I'm pretty sure that there are some UX design patterns available somewhere. If we would like to have a rules, I would suggest that something that changes the screenshot used in the user documentation should be approved, especially when it doesn't add features. Eric On 2016-05-31 15:49, Kyle Hall wrote: I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all! Kyle Sent from my phone. Please excuse my brevity. On May 31, 2016 3:32 PM, "Christopher Davis" <<mailto:cgdavis@uintah.utah.gov>cgdavis@uintah.utah.gov<mailto:cgdavis@uintah.utah.gov>> wrote: Owen, I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings? My $0.02 worth, Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov<mailto:cgdavis@uintah.utah.gov> (435) 789-0091 ext.261<tel:%28435%29%20789-0091%20ext.261> uintahlibrary.org<http://uintahlibrary.org> basinlibraries.org<http://basinlibraries.org> facebook.com/uintahcountylibrary<http://facebook.com/uintahcountylibrary> instagram.com/uintahcountylibrary<http://instagram.com/uintahcountylibrary> On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org<mailto:oleonard@myacpl.org>> wrote:
Could the new features which you are proposing be optional?
They're not really new features, they're just changes to the way existing features look. We can't build options for every change we want to make to the interface. We need to make educated choices about what we think is the best way for things to work. We may not always get it right, but it's our job to make the choice.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : <http://www.koha-community.org/> http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Yes, I think we need one single document for all developer guidelines, and I think the Developer's Handbook is the way to go. I think I can highlight the problem by confessing that I've never even seen ( or least didn't remember ) that Interface Patterns page before! We need a single source for developer rules and regulations simply so they don't get lost in the shuffle. Basically, if there is a rule or guideline that should affect how Koha developers plan and write their code, it should be in the Developer's Handbook Kyle <https://secure2.convio.net/cffh/site/Donation2?df_id=1395&FR_ID=4715&PROXY_ID=2706639&PROXY_TYPE=20&1395.donation=form1&s_src=CHORUS&s_subsrc=CHAADOEB> http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) On Wed, Jun 1, 2016 at 2:13 AM, Marc Véron <veron@veron.ch> wrote:
+1 for 'Style guidelines' and 'GUI manager'
Regarding the Wiki: https://wiki.koha-community.org/wiki/Interface_patterns https://wiki.koha-community.org/wiki/Developers_Handbook (1.2 User Interface)
Should this be consolidated in one document?
Marc
Am 01.06.2016 um 02:43 schrieb Kyle Hall:
I think you've summarized everything nicely. If Owen were interested in taking some official mantel I would not be opposed ; )
I think we need to focus on expediency and uniformity primarily. I think we basically have those two things, but they could both be improved. I would be more than happy to work on adding a UI guidelines section to the wiki. For those interested, here is what I've done so far: <https://wiki.koha-community.org/wiki/Developers_Handbook> https://wiki.koha-community.org/wiki/Developers_Handbook
It's a bit rough now because it's really guideline-centric, but I think over time it will come into its own quite nicely. Constructive criticism is welcome!
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( <http://www.meadvillelibrary.org> http://www.meadvillelibrary.org ) Crawford County Federated Library System ( <http://www.ccfls.org> http://www.ccfls.org )
On Tue, May 31, 2016 at 5:26 PM, Katrin <katrin.fischer.83@web.de> wrote:
I like the idea of having a role like 'GUI manager' and also the idea of having style guidelines for the interfaces. Actually, I think. we already have both of those, as Owen has been working on writing documentation about existing patterns on the wiki.
I am not in favor of approving every change that would change the screenshots, as that would make the clean-up work much harder, that Owen, Aleisha and others have done recently. For bigger changes I'd try sending links to screenshots/bug reports to the mailing list to get some opinions - if there is no clear direction, we can still schedule an official discussion/vote at a meeting.
Katrin
On 31.05.2016 23:54, Kyle Hall wrote:
Love it! I'd say this is a much better idea!
Kyle
Sent from my phone. Please excuse my brevity. On May 31, 2016 4:25 PM, "Eric Bégin" <eric.begin@inlibro.com> wrote:
I would rather have a Interface guideline the same way we have coding guidelines.
I'm pretty sure that there are some UX design patterns available somewhere.
If we would like to have a rules, I would suggest that something that changes the screenshot used in the user documentation should be approved, especially when it doesn't add features.
Eric
On 2016-05-31 15:49, Kyle Hall wrote:
I'm concerned that we are going down a road where every patch submitted to the Koha project will end up requiring a community vote. I think it would be more reasonable and efficient to add a community UI manager role to the project. Someone who is empowered to make executive decisions on this matter. Either that or accept that the way team rules on this matter. The community votes them in after all!
Kyle
Sent from my phone. Please excuse my brevity. On May 31, 2016 3:32 PM, "Christopher Davis" < <cgdavis@uintah.utah.gov> cgdavis@uintah.utah.gov> wrote:
Owen,
I think that Koha users should voice their opinion/votes as that the Koha software, more or less, belongs to them. Now, what vehicle should we use to collect everyone's opinion/vote (like Survey Monkey, Google forms, IRC voting, etc.) and should there be a committee formed for this purpose? Maybe decisions such as this one should be voted on during Koha Devl IRC meetings?
My $0.02 worth,
Christopher Davis, MLS Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 ext.261 <%28435%29%20789-0091%20ext.261> uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary
On Tue, May 31, 2016 at 1:01 PM, Owen Leonard <oleonard@myacpl.org> wrote:
Could the new features which you are proposing be optional?
They're not really new features, they're just changes to the way existing features look. We can't build options for every change we want to make to the interface. We need to make educated choices about what we think is the best way for things to work. We may not always get it right, but it's our job to make the choice.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : <http://www.koha-community.org/> http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
It sounds like there is no urgent desire to change the workflow, which is good because I think that means nobody is upset about any recent interface changes. I think that maintaining the interface guidelines and pattern documentation is a good idea, and I will continue to do so. I don't think that we can write guidelines which will cover every situation, so I think there will be times when a developer would be advised to come to the koha-devel list with questions or proposals. Thanks everyone for your comments! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Lots of great comments here from everyone. For my part, I'd love to see Owen as benevolent dictator of Koha's GUI. I think he has the most experience, interest, and skill out of all of us in this area. If he's happy to let us rule ourselves using interface guidelines located in the developer handbook, and occasionally bring down a ruling or carve a new pathway, I think that sounds good too. As Kyle says, I think we need something practical but also something which provides uniformity. A keystone of UX is predictability. We need to provide users with a consistent and predictable interface if they're going to have a good experience with Koha. Honestly, I think most developers (not just Koha developers) are really bad at UX. While I know the theory, I'm not that great at it myself, and it's because most of the time I'm focused on functionality rather than UX. An additional idea... are there some heuristics that we can give to the QA team? Sort of like... a slim set of rules which they can use to fail/pass a template? Otherwise, the guidelines don't do much good. I think QA and the RM need to have an intimate understanding of the guidelines, otherwise we're just hoping that people follow them without verifying in any way that they do. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595
Salvete!
For my part, I'd love to see Owen as benevolent dictator of Koha's GUI. I think he has the most experience, interest, and skill out of all of us in this area.
This is +1 from me, but I should hope this discussion migrates over to the plain vanilla Koha list. It is where a bulk of the Users are, after all. Cheers, Brooke
Did this discussion ever go anywhere? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Owen Leonard Sent: Wednesday, 1 June 2016 4:30 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] How do we find consensus on interface changes?
Do we need a procedure for getting consensus on Koha interface changes?
I'm thinking about this issue in part because of a couple of interface changes I've been working on. One for Bug 16421:
Move hold edit actions into dropdown menu https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 (screenshot: https://bugs.koha- community.org/bugzilla3/attachment.cgi?id=51111)
...and another for Bug 11375:
Patron permission names are untranslatable https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11375 (screenshot: https://bugs.koha- community.org/bugzilla3/attachment.cgi?id=51847)
When proposing a change like that should there be a more inclusive process than getting one sign-off and one QA approval? If so, how do we decide what kind of changes require wider approval? How do we solicit opinions from a wider audience?
Or is the process working well as-is?
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha- community.org/ bugs : http://bugs.koha-community.org/
participants (9)
-
BWS Johnson -
Christopher Davis -
David Cook -
Eric Bégin -
Katrin -
Kyle Hall -
Marc Véron -
Marcel de Rooy -
Owen Leonard