[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Review Request: KHolidays: New Holiday Region Selection widget
From: "John Layt" <johnlayt () googlemail ! com>
Date: 2010-10-04 15:22:18
Message-ID: 20101004152218.28467.59019 () vidsolbach ! de
[Download RAW message or body]
> On 2010-10-04 13:16:27, David Jarvie wrote:
> > I wonder whether it would be better to group countries by continent, as=
for time zone selection. One reason might be if there were cases where a u=
ser's country is not in the list, but a neighbouring country might supply s=
uitable holidays - in this case, grouping by continent would make it easier=
to find a neighbouring country (bearing in mind that not all other countri=
es will be in the list either).
> > =
> > I don't think the default column heading "Select" is intuitive enough w=
hen "Days Off" is displayed alongside. I suspect that many people (myself i=
ncluded) would normally equate "holiday" with "day off". In this case, it i=
sn't obvious what the "Select" column would be for. Having some acquaintanc=
e with KDE holiday files, I think I may know what the distinction is, but w=
ithout knowing KDE holiday files I'd be completely in the dark. In any case=
, it would be more natural for the "Days Off" column to precede the "Select=
" column (suitably renamed).
> > =
> > In the documentation in the header, there should be an explanation as t=
o why or why not a developer should choose to display the Language column. =
It isn't obvious, to me at least, that language would be relevant to choosi=
ng a holiday region. If one language was spoken in one region and another w=
as spoken in another region, then I'd expect the holidays to be different, =
but that would be because it was a different region. And if a single holida=
y had a different name in one language from another, I'd expect the display=
ed name to follow the user's locale language, not the holiday file's.
> > =
> > It's a pity that your indent will have to be changed to 2 spaces - it's=
much more legible using 4 spaces.
Some good points to think about.
I'm not sure about Continents, as that would make it less obvious for the m=
ain use case when finding your country when it does exist. I'll have a pla=
y with the idea anyway. The region name ordering does need some improvemen=
t, I'm working on some changes for holiday types which would allow us to sp=
lit things up more so that should help. Once we have more categories to se=
lect from then better sorting will be possible, in fact desirable as we wil=
l have non-geographical region based files.
I did struggle with the select/days-off thing. The main use case would be =
where for example a UK business user wants to show on his calendar the holi=
days for England, Germany and the USA so he knows when his business clients=
have holidays, but obviously only wants the England holidays to count as D=
ays Off for his scheduling or showing red highlights. You're right the pri=
mary use is for a single region and it should default to being used as Days=
Off, it just seemed to me to have the second column be an opt-out named "D=
on't use for Days Off" was more awkward and inconsitent, i.e. one tick work=
s as opt-in and the other as opt-out. Perhaps clicking the first column sh=
ould automatically select the second? This will become especially importan=
t when we have categories and separate files for Public, Religious and Cult=
ural holidays and more users will have cause to select multiple files. I w=
onder if a combo box with values for "Don't Use", "Info Only", and "Days Of=
f" might be better (but that wouldn't work in single selection mode)? The =
tooltip and whatsthis probably need to explain the difference better, but i=
t does depend on what the client uses it for, e.g. KOrganizer will use Days=
Off for scheduling, but the Plasma Clock will only use it for colouring da=
ys.
The Language column is an artifact of the holiday region files only support=
ing a single language and not having any translations available, without di=
splaying the language the user wouldn't know which they were getting. For =
example, Belgium has 3 official languages, ideally there would be a single =
holiday region file for the national holidays with i18n() taking care of th=
e rest, but that's not possible yet (hopefully in 4.7 with a new xml file f=
ormat and proper i18n tools). I did think of only showing files available =
in the users language, but that would prevent multilingual people using fil=
es they need that are only in other languages. So I left that to the app t=
o decide if they wanted to filter for language. Also if the app doesn't ha=
ve much space they could hide the language column and just rely on the tool=
tip to show the difference. Perhaps the middle ground would be to initiall=
y only list the current language, but have a button or tickbox to show all =
languages? Anyway, I'll improve the docs.
- John
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5518/#review7963
-----------------------------------------------------------
On 2010-10-02 18:21:32, John Layt wrote:
> =
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5518/
> -----------------------------------------------------------
> =
> (Updated 2010-10-02 18:21:32)
> =
> =
> Review request for kdelibs and KDE PIM.
> =
> =
> Summary
> -------
> =
> Implement a standard widget in the KHolidays library for clients to use t=
o allow users to select holiday regions to be displayed. The widget provid=
es a number of modes and features to fit most use case scenarios I can thin=
k of:
> * A display only mode
> * A single Holiday Region selection mode
> * A multiple Holiday Region selection mode with optional secondary select=
ion for Days Off / preferred Holiday Region
> * A search line
> * Ability to modify level of detail displayed when space is limited
> =
> Some points to think about:
> 1) I've implemented Qt Designer plugin support for the widget using a KHo=
lidays specific plugin, but should the Designer support actually be at kdep=
imlibs level instead, i.e. all kdepimlibs widgets in a single shared plugi=
n?
> 2) Naming of the widget, enum and api calls
> 3) The layout of the selection boxes and columns
> =
> =
> Diffs
> -----
> =
> /trunk/KDE/kdepimlibs/includes/KHolidays/HolidayRegionSelector PRE-CREA=
TION =
> /trunk/KDE/kdepimlibs/kholidays/CMakeLists.txt 1180311 =
> /trunk/KDE/kdepimlibs/kholidays/holidayregionselector.h PRE-CREATION =
> /trunk/KDE/kdepimlibs/kholidays/holidayregionselector.cpp PRE-CREATION =
> /trunk/KDE/kdepimlibs/kholidays/holidayregionselector.ui PRE-CREATION =
> /trunk/KDE/kdepimlibs/kholidays/kholidays.widgets PRE-CREATION =
> =
> Diff: http://svn.reviewboard.kde.org/r/5518/diff
> =
> =
> Testing
> -------
> =
> Test client implementation done in the Plasma clock/calendar.
> =
> =
> Screenshots
> -----------
> =
> Widget example
> http://svn.reviewboard.kde.org/r/5518/s/523/
> =
> =
> Thanks,
> =
> John
> =
>
[Attachment #3 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://svn.reviewboard.kde.org/r/5518/">http://svn.reviewboard.kde.org/r/5518/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On October 4th, 2010, 1:16 p.m., <b>David \
Jarvie</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">I wonder whether it would be better to group countries by continent, as \
for time zone selection. One reason might be if there were cases where a user's \
country is not in the list, but a neighbouring country might supply suitable holidays \
- in this case, grouping by continent would make it easier to find a neighbouring \
country (bearing in mind that not all other countries will be in the list either).
I don't think the default column heading "Select" is intuitive enough \
when "Days Off" is displayed alongside. I suspect that many people (myself \
included) would normally equate "holiday" with "day off". In this \
case, it isn't obvious what the "Select" column would be for. Having \
some acquaintance with KDE holiday files, I think I may know what the distinction is, \
but without knowing KDE holiday files I'd be completely in the dark. In any case, \
it would be more natural for the "Days Off" column to precede the \
"Select" column (suitably renamed).
In the documentation in the header, there should be an explanation as to why or why \
not a developer should choose to display the Language column. It isn't obvious, \
to me at least, that language would be relevant to choosing a holiday region. If one \
language was spoken in one region and another was spoken in another region, then \
I'd expect the holidays to be different, but that would be because it was a \
different region. And if a single holiday had a different name in one language from \
another, I'd expect the displayed name to follow the user's locale language, \
not the holiday file's.
It's a pity that your indent will have to be changed to 2 spaces - it's much \
more legible using 4 spaces.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Some good points to \
think about.
I'm not sure about Continents, as that would make it less obvious for the main \
use case when finding your country when it does exist. I'll have a play with the \
idea anyway. The region name ordering does need some improvement, I'm working on \
some changes for holiday types which would allow us to split things up more so that \
should help. Once we have more categories to select from then better sorting will be \
possible, in fact desirable as we will have non-geographical region based files.
I did struggle with the select/days-off thing. The main use case would be where for \
example a UK business user wants to show on his calendar the holidays for England, \
Germany and the USA so he knows when his business clients have holidays, but \
obviously only wants the England holidays to count as Days Off for his scheduling or \
showing red highlights. You're right the primary use is for a single region and \
it should default to being used as Days Off, it just seemed to me to have the second \
column be an opt-out named "Don't use for Days Off" was more awkward \
and inconsitent, i.e. one tick works as opt-in and the other as opt-out. Perhaps \
clicking the first column should automatically select the second? This will become \
especially important when we have categories and separate files for Public, Religious \
and Cultural holidays and more users will have cause to select multiple files. I \
wonder if a combo box with values for "Don't Use", "Info \
Only", and "Days Off" might be better (but that wouldn't work in \
single selection mode)? The tooltip and whatsthis probably need to explain the \
difference better, but it does depend on what the client uses it for, e.g. KOrganizer \
will use Days Off for scheduling, but the Plasma Clock will only use it for colouring \
days.
The Language column is an artifact of the holiday region files only supporting a \
single language and not having any translations available, without displaying the \
language the user wouldn't know which they were getting. For example, Belgium \
has 3 official languages, ideally there would be a single holiday region file for the \
national holidays with i18n() taking care of the rest, but that's not possible \
yet (hopefully in 4.7 with a new xml file format and proper i18n tools). I did think \
of only showing files available in the users language, but that would prevent \
multilingual people using files they need that are only in other languages. So I \
left that to the app to decide if they wanted to filter for language. Also if the \
app doesn't have much space they could hide the language column and just rely on \
the tooltip to show the difference. Perhaps the middle ground would be to initially \
only list the current language, but have a button or tickbox to show all languages? \
Anyway, I'll improve the docs.</pre> <br />
<p>- John</p>
<br />
<p>On October 2nd, 2010, 6:21 p.m., John Layt wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://svn.reviewboard.kde.orgrb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for kdelibs and KDE PIM.</div>
<div>By John Layt.</div>
<p style="color: grey;"><i>Updated 2010-10-02 18:21:32</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Implement a standard widget in the KHolidays library for clients to use \
to allow users to select holiday regions to be displayed. The widget provides a \
number of modes and features to fit most use case scenarios I can \
think of:
* A display only mode
* A single Holiday Region selection mode
* A multiple Holiday Region selection mode with optional secondary selection for Days \
Off / preferred Holiday Region
* A search line
* Ability to modify level of detail displayed when space is limited
Some points to think about:
1) I've implemented Qt Designer plugin support for the widget using a KHolidays \
specific plugin, but should the Designer support actually be at kdepimlibs level \
instead, i.e. all kdepimlibs widgets in a single shared plugin? 2) Naming of the \
widget, enum and api calls 3) The layout of the selection boxes and columns
</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Test client implementation done in the Plasma clock/calendar.</pre> \
</td> </tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/KDE/kdepimlibs/includes/KHolidays/HolidayRegionSelector <span \
style="color: grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdepimlibs/kholidays/CMakeLists.txt <span style="color: \
grey">(1180311)</span></li>
<li>/trunk/KDE/kdepimlibs/kholidays/holidayregionselector.h <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdepimlibs/kholidays/holidayregionselector.cpp <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdepimlibs/kholidays/holidayregionselector.ui <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>/trunk/KDE/kdepimlibs/kholidays/kholidays.widgets <span style="color: \
grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/5518/diff/" style="margin-left: \
3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Screenshots </h1>
<div>
<a href="http://svn.reviewboard.kde.org/r/5518/s/523/"><img \
src="http://svn.reviewboard.kde.org/media/uploaded/images/2010/10/02/HolidaysMultipleSelector_400x100.jpg" \
style="border: 1px black solid;" alt="Widget example" /></a>
</div>
</td>
</tr>
</table>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic