Re: Page numbers on background

classic Classic list List threaded Threaded
21 messages Options
Next » 12
Phil Howard Phil Howard
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

Forking thread:

> Mirek M:
>> Since everyone's putting their UI proposal up, I'll do so too:
>> http://wiki.documentfoundation.org/User:Mirek2 .

On Thu, Jun 23, 2011 at 10:42 AM, Astron <[hidden email]> wrote:
> I found the page number next to every page so useful that I
> immediately opened a bug for it, I hope this was not completely
> uncalled for, anyway, the bug is here:
> https://bugs.freedesktop.org/show_bug.cgi?id=38597 .

Agree it's a good proposal to show the page number. However, if the
user has zoomed in or resized their window and can't see the number
any more, then you end up needing the page number elsewhere on the
screen as well, and if they can't see all of the page on the screen
they probably don't want to lose more space to toolbars/statusbars.

I would suggest that the page number floated beside the top left/right
corner of the *visible* page. Then when you are looking at the bottom
of page 2 and the top of page 3, you'd see the 2 at the top and the 3
beside the corner of page 3. It could even float on the page with a
very light colour when the user can't see the document window
background.

Additional benefit - when the user scrolls quickly by dragging the
scroll bar, the page marker would stay in the same place.

Further development could be to add contextual actions if the user
selects the page number - go to page N, insert page, etc.

Incidentally, if the user displays facing pages, the page numbers will
need to be positioned correctly either side of the spread.

Philip H

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

Hi Phil, RGB, Mirek (I'll just post in this thread that Phil forked
instead of the original one), hi everyone else, too (there's a little
survey a -- please answer :) )

Okay, first:
> Incidentally, if the user displays facing pages, the page numbers will
> need to be positioned correctly either side of the spread.

That's correct. So many things one sometimes simply overlooks with UIs. I agree.

Next:
> Agree it's a good proposal to show the page number. However, if the
> user has zoomed in or resized their window and can't see the number
> any more, then you end up needing the page number elsewhere on the
> screen as well, and if they can't see all of the page on the screen
> they probably don't want to lose more space to toolbars/statusbars.

It should still be displayed in the tooltip when moving the
scrollbars. But in my view it could be removed from the status bar (I
never found the page display useful because it's always small and out
of one's view).


> I would suggest that the page number floated beside the top left/right
> corner of the *visible* page. Then when you are looking at the bottom
> of page 2 and the top of page 3, you'd see the 2 at the top and the 3
> beside the corner of page 3.

That would make the number even more useful, but would make it also
feel less "physical" (if that is a category that even applies to a
number that is diplayed /beside/ a document). It might also get in the
way, because then it wouldn't always be at the top of the page – but
that's probably something minor as long as the number really stays put
until a new number comes in. So yes, that's a good idea.


> It could even float on the page with a
> very light colour when the user can't see the document window
> background.

The page number should, in my view, hide when it's in the way. It
would probably be possible to put the number as a watermark in the
background of pages, but I don't like the idea too much, because it
would confuse users unnecessarily.
When users zoom in, the number should simply be cut off at the edges
and scrollbars shouldn't allow to scroll in the area cut off. Before
trying to argue for this, maybe a little survey could help:


THE SURVEY:
1. What's your screen size and resolution (most of the time)?
2. What paper format do you use?
3. Do you work in full-screen?
4. Do you use any multi-page mode (for instance two pages in one screen?


For me, that's:
1. 14" / 1440 * 900
2. A4 (sometimes A5 and A6)
3. Yes, always.
4. No.


> Further development could be to add contextual actions if the user
> selects the page number - go to page N, insert page, etc.

That's really clever, but to reconcile it with my view of how the page
numbers should behave, the number would have to slide in again, for
instance, once you throw your mouse towards the edge of the screen.
This would make the bug far harder to implement and would probably
mean the idea would stay in the mailing list forever. So, let's
postpone this discussion.


@RGB ES/Mirek:
> Which page number? The "physical" page number, the "printed" page number, both?
> At least on Writer it is quite common that page 1 is the "physical"
> page 7, for example.
> I vote for "both" ;)

I'm there with Mirek voting for only physical page number. It's seems
more useful for e.g. finding out on which page you are or finding a
print range. As Mirek said, the printed page number is also displayed
on the doument itself. Nevertheless there are a few other solutions
here:
* make it configurable (which would be lowest common denominator, but
given that LibO already has so many knobs, buttons and screws this
seems a bad solution
* present both, but only if they _differ_, with the "printed" value
smaller and below the "physical" value.

Astron

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
RGB.ES RGB.ES
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

2011/6/23 Astron <[hidden email]>:
> THE SURVEY:
> 1. What's your screen size and resolution (most of the time)?
> 2. What paper format do you use?
> 3. Do you work in full-screen?
> 4. Do you use any multi-page mode (for instance two pages in one screen?
>
>
1. 17" / 1440 * 900
2. It depends on the document, but mainly A4 and A5
3. No, never. I only use full-screen for movies :)
4. Yes. I have several complex documents and I need to see both, main
text and appendixes, for example. A split screen would make me
reconsider point 3...

>
> @RGB ES/Mirek:
>> Which page number? The "physical" page number, the "printed" page number, both?
>> At least on Writer it is quite common that page 1 is the "physical"
>> page 7, for example.
>> I vote for "both" ;)
>
> I'm there with Mirek voting for only physical page number. It's seems
> more useful for e.g. finding out on which page you are or finding a
> print range. As Mirek said, the printed page number is also displayed
> on the doument itself. Nevertheless there are a few other solutions
> here:
> * make it configurable (which would be lowest common denominator, but
> given that LibO already has so many knobs, buttons and screws this
> seems a bad solution
> * present both, but only if they _differ_, with the "printed" value
> smaller and below the "physical" value.

+1 for last option.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Sveinn í Felli Sveinn í Felli
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Phil Howard

2011/6/23 Astron <[hidden email]>:
>
> THE SURVEY:
> 1. What's your screen size and resolution (most of the time)?
> 2. What paper format do you use?
> 3. Do you work in full-screen?
> 4. Do you use any multi-page mode (for instance two pages in one screen?

My responses:
1. 23" / 1920 * 1080
2. A4 (sometimes A5) mostly portrait in Writer, landscape in
Calc
3. Sometimes.
4. Yes, often comparing texts, translating, versioning.

----------

> @RGB ES/Mirek:
>> Which page number? The "physical" page number, the "printed" page number, both?
>> At least on Writer it is quite common that page 1 is the "physical"
>> page 7, for example.
>> I vote for "both" ;)
>
> I'm there with Mirek voting for only physical page number. It's seems
> more useful for e.g. finding out on which page you are or finding a
> print range. As Mirek said, the printed page number is also displayed
> on the doument itself. Nevertheless there are a few other solutions
> here:
> * make it configurable (which would be lowest common denominator, but
> given that LibO already has so many knobs, buttons and screws this
> seems a bad solution
> * present both, but only if they _differ_, with the "printed" value
> smaller and below the "physical" value.
>

I recall a complex report I once (ages ago) had to manage in
MSWord; with appendixes in Roman numerals, lots of
independently numbered sections, indexes and stuff. Quite a
mess, and the poor program choked regularly on the page
ranges (renumbering the sections). Getting around was not
easy, I would have liked indicators of both 'nominal' page
number and 'real/physical' page number. Both in the status
bar and as tooltip on the scrollbar.

Something like: [nominal - physical / total]
e.g:  xvii - 56/264 and  3 - 59/264

Hope you get the idea from my meager explanation, maybe it's
too complicated anyway.

Best regards,
Sveinn í Felli


--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Jean Weber Jean Weber
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
On Thu, 2011-06-23 at 17:59 +0200, Astron wrote:
> Hi Phil, RGB, Mirek (I'll just post in this thread that Phil forked
> instead of the original one), hi everyone else, too (there's a little
> survey a -- please answer :) )
>

> THE SURVEY:
> 1. What's your screen size and resolution (most of the time)?
> 2. What paper format do you use?
> 3. Do you work in full-screen?
> 4. Do you use any multi-page mode (for instance two pages in one screen?

My answers:
1. 27-inch, 1920x1200
2. A4
3. No
4. Yes, but more often I use two documents side-by-side

--Jean


--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Phil Howard Phil Howard
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
On Thu, Jun 23, 2011 at 4:59 PM, Astron <[hidden email]> wrote:
>> user has zoomed in or resized their window and can't see the number
> It should still be displayed in the tooltip ...

>> I would suggest that the page number floated beside the top left/right
>> corner of the *visible* page.
> That would make the number even more useful, but would make it also
> feel less "physical"

I know what you mean. I am generally for more anchored and zoomable UI
elements. But only if the user knows how to zoom/pan quickly.

I do use a Visual Studio plugin which shows a miniature preview
*instead* of the scroll bar, so scrolling is synonymous with clicking
on the document preview. It's quite a nice zoom-style metaphor, and we
could have the page numbers fade in over pages if needed when
scrolling more than a short distance. I'd call that
dynamic/action-contextual UI.

>> THE SURVEY:
>> 1. What's your screen size and resolution (most of the time)?
1440/900 (15") or 1920/1080+1280/1024 (27"+19")
>> 2. What paper format do you use?
A4
>> 3. Do you work in full-screen?
On the laptop, mostly, on the desktop rarely.
>> 4. Do you use any multi-page mode (for instance two pages in one screen?
Yes for review/comparisons, constructing mockups from screenshots
(page numbers there too!)

>> Further development could be to add contextual actions if the user
>> selects the page number - go to page N, insert page, etc.
> That's really clever, but ... far harder ... mailing list forever. So, let's
> postpone this discussion.
Agreed. I like to throw in far-fetched ideas, but it was not meant as
a suggestion for this iteration.

> @RGB ES/Mirek:
>> Which page number? The "physical" page number, the "printed" page number, both?
> I'm there with Mirek voting for only physical page number.
> other solutions
> * make it configurable (... seems a bad solution
> * present both, but only if they _differ_, with the "printed" value
> smaller and below the "physical" value.
I'm with you here. Prefer just one, certainly don't show two numbers
the same. Different sizes and different colours might just about swing
it, though, as the suite acts as a viewer as well as an editor, and
people prefer to have 1 mapping in their head ('change font size on
page xvii. Wait, is that page 17, or 16, or...').

One use case in my head was inserting an envelope at the beginning of
a multipage letter. To most people, the envelope is the envelope, and
page 1 is the first full page. But I would hazard a guess that almost
all office suites mark that as pages 1 and 2.

If I was to carry on down this road, I'd suggest having an indicator
of the current section/chapter as well - again people have 1 mapping
and that is often the document structure rather than the page number
when looking at an electronic document. Also, legal stuff is all
section 3 paragraph 2 sentence 6, not page 7 line 3.

If the user can see all these (default is just the page number) they
can be given, upon hovering, the option to hide the others for now or
for ever.

My vote is just show the page number, as originally suggested, at the
top left corner of the screen, and refine any further proposals as a
separate stage.

Philip H

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Phil Howard
Hi Phil, everyone,

2011/6/23 Phil Howard <[hidden email]>

> Forking thread:
>
> > Mirek M:
> >> Since everyone's putting their UI proposal up, I'll do so too:
> >> http://wiki.documentfoundation.org/User:Mirek2 .
>
> On Thu, Jun 23, 2011 at 10:42 AM, Astron <[hidden email]>
> wrote:
> > I found the page number next to every page so useful that I
> > immediately opened a bug for it, I hope this was not completely
> > uncalled for, anyway, the bug is here:
> > https://bugs.freedesktop.org/show_bug.cgi?id=38597 .
>
> Agree it's a good proposal to show the page number. However, if the
> user has zoomed in or resized their window and can't see the number
> any more, then you end up needing the page number elsewhere on the
> screen as well, and if they can't see all of the page on the screen
> they probably don't want to lose more space to toolbars/statusbars.
>

The number will be shown on the status bar, just as it is now. Besides, if
the user zooms in that much, then the thing he really needs to see is the
document content, not the page number, and putting the page number anywhere
will just take away valuable space.

>
> I would suggest that the page number floated beside the top left/right
> corner of the *visible* page. Then when you are looking at the bottom
> of page 2 and the top of page 3, you'd see the 2 at the top and the 3
> beside the corner of page 3.


It's definitely something worth looking into.


> It could even float on the page with a
> very light colour when the user can't see the document window
> background.
>

I'd be against this sort of overlay -- it could very easily get in the way,
and if the button ever became clickable in future iterations, it couldn't be
shown in a page.

>
> Additional benefit - when the user scrolls quickly by dragging the
> scroll bar, the page marker would stay in the same place.
>
> Further development could be to add contextual actions if the user
> selects the page number - go to page N, insert page, etc.
>

In the original (Citrus UI) proposal, the number also serves as a page (or
slide) handle. When you click it, you get a contextual toolbar with all the
commands pertaining to the page [group]: page style, layout, format,
orientation, margins, columns, borders, header, footer, etc.

Also in the proposal, a special "Add page" button appears at the end of a
document.

This could all, of course, be implemented after the page numbers.

>
> Incidentally, if the user displays facing pages, the page numbers will
> need to be positioned correctly either side of the spread.
>
> Philip H
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Patrick Scott Patrick Scott
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Phil Howard
Hi all,

I agree with having just the physical page number and I'd be okay with it
being cut off if the user zooms in (rather that than block off some of the
document). However, I'd like to have the page number float on the left side
of the document and stay on screen as the user scrolls down the page as was
earlier suggested in this thread. That being said, I'd like this improvement
to not be damned to the mailing list for eternity and would be willing to
compromise on the floaty awesomeness!

On a side note, when fast-scrolling through artists on an iPod classic or
contacts on an Android phone (and probably iPhone), the first letter of the
current artists/contacts you're scrolling through is shown front and centre
on screen in a huge transparent font. Something similar to this could be
quite nice in LO with page numbers in Writer and Slide numbers in Impress.

Thanks,
Patrick


On 23 June 2011 23:31, Phil Howard <[hidden email]> wrote:

> On Thu, Jun 23, 2011 at 4:59 PM, Astron <[hidden email]>
> wrote:
> >> user has zoomed in or resized their window and can't see the number
> > It should still be displayed in the tooltip ...
>
> >> I would suggest that the page number floated beside the top left/right
> >> corner of the *visible* page.
> > That would make the number even more useful, but would make it also
> > feel less "physical"
>
> I know what you mean. I am generally for more anchored and zoomable UI
> elements. But only if the user knows how to zoom/pan quickly.
>
> I do use a Visual Studio plugin which shows a miniature preview
> *instead* of the scroll bar, so scrolling is synonymous with clicking
> on the document preview. It's quite a nice zoom-style metaphor, and we
> could have the page numbers fade in over pages if needed when
> scrolling more than a short distance. I'd call that
> dynamic/action-contextual UI.
>
> >> THE SURVEY:
> >> 1. What's your screen size and resolution (most of the time)?
> 1440/900 (15") or 1920/1080+1280/1024 (27"+19")
> >> 2. What paper format do you use?
> A4
> >> 3. Do you work in full-screen?
> On the laptop, mostly, on the desktop rarely.
> >> 4. Do you use any multi-page mode (for instance two pages in one screen?
> Yes for review/comparisons, constructing mockups from screenshots
> (page numbers there too!)
>
> >> Further development could be to add contextual actions if the user
> >> selects the page number - go to page N, insert page, etc.
> > That's really clever, but ... far harder ... mailing list forever. So,
> let's
> > postpone this discussion.
> Agreed. I like to throw in far-fetched ideas, but it was not meant as
> a suggestion for this iteration.
>
> > @RGB ES/Mirek:
> >> Which page number? The "physical" page number, the "printed" page
> number, both?
> > I'm there with Mirek voting for only physical page number.
> > other solutions
> > * make it configurable (... seems a bad solution
> > * present both, but only if they _differ_, with the "printed" value
> > smaller and below the "physical" value.
> I'm with you here. Prefer just one, certainly don't show two numbers
> the same. Different sizes and different colours might just about swing
> it, though, as the suite acts as a viewer as well as an editor, and
> people prefer to have 1 mapping in their head ('change font size on
> page xvii. Wait, is that page 17, or 16, or...').
>
> One use case in my head was inserting an envelope at the beginning of
> a multipage letter. To most people, the envelope is the envelope, and
> page 1 is the first full page. But I would hazard a guess that almost
> all office suites mark that as pages 1 and 2.
>
> If I was to carry on down this road, I'd suggest having an indicator
> of the current section/chapter as well - again people have 1 mapping
> and that is often the document structure rather than the page number
> when looking at an electronic document. Also, legal stuff is all
> section 3 paragraph 2 sentence 6, not page 7 line 3.
>
> If the user can see all these (default is just the page number) they
> can be given, upon hovering, the option to hide the others for now or
> for ever.
>
> My vote is just show the page number, as originally suggested, at the
> top left corner of the screen, and refine any further proposals as a
> separate stage.
>
> Philip H
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
Hi Astron,

2011/6/23 Astron <[hidden email]>

> Hi Phil, RGB, Mirek (I'll just post in this thread that Phil forked
> instead of the original one), hi everyone else, too (there's a little
> survey a -- please answer :) )
>
> Okay, first:
> > Incidentally, if the user displays facing pages, the page numbers will
> > need to be positioned correctly either side of the spread.
>
> That's correct. So many things one sometimes simply overlooks with UIs. I
> agree.
>

+1

>
> Next:
> > Agree it's a good proposal to show the page number. However, if the
> > user has zoomed in or resized their window and can't see the number
> > any more, then you end up needing the page number elsewhere on the
> > screen as well, and if they can't see all of the page on the screen
> > they probably don't want to lose more space to toolbars/statusbars.
>
> It should still be displayed in the tooltip when moving the
> scrollbars. But in my view it could be removed from the status bar (I
> never found the page display useful because it's always small and out
> of one's view).
>
> > I would suggest that the page number floated beside the top left/right
> > corner of the *visible* page. Then when you are looking at the bottom
> > of page 2 and the top of page 3, you'd see the 2 at the top and the 3
> > beside the corner of page 3.
>
> That would make the number even more useful, but would make it also
> feel less "physical" (if that is a category that even applies to a
> number that is diplayed /beside/ a document). It might also get in the
> way, because then it wouldn't always be at the top of the page – but
> that's probably something minor as long as the number really stays put
> until a new number comes in. So yes, that's a good idea.
>
> > It could even float on the page with a
> > very light colour when the user can't see the document window
> > background.
>
> The page number should, in my view, hide when it's in the way. It
> would probably be possible to put the number as a watermark in the
> background of pages, but I don't like the idea too much, because it
> would confuse users unnecessarily.
>

I agree.


> When users zoom in, the number should simply be cut off at the edges
> and scrollbars shouldn't allow to scroll in the area cut off. Before
> trying to argue for this, maybe a little survey could help:
>
> THE SURVEY:
> 1. What's your screen size and resolution (most of the time)?
>
 1024 x 576

> 2. What paper format do you use?
>
A4

> 3. Do you work in full-screen?
>
Maximized window, yes. (Not true full-screen.)

> 4. Do you use any multi-page mode (for instance two pages in one screen?)
>
Very rarely.

>
>
>
> > Further development could be to add contextual actions if the user
> > selects the page number - go to page N, insert page, etc.
>
> That's really clever, but to reconcile it with my view of how the page
> numbers should behave, the number would have to slide in again, for
> instance, once you throw your mouse towards the edge of the screen.
> This would make the bug far harder to implement and would probably
> mean the idea would stay in the mailing list forever. So, let's
> postpone this discussion.
>
>
> @RGB ES/Mirek:
> > Which page number? The "physical" page number, the "printed" page number,
> both?
> > At least on Writer it is quite common that page 1 is the "physical"
> > page 7, for example.
> > I vote for "both" ;)
>
> I'm there with Mirek voting for only physical page number. It's seems
> more useful for e.g. finding out on which page you are or finding a
> print range. As Mirek said, the printed page number is also displayed
> on the doument itself. Nevertheless there are a few other solutions
> here:
> * make it configurable (which would be lowest common denominator, but
> given that LibO already has so many knobs, buttons and screws this
> seems a bad solution
>

I agree -- fit for an "Advanced settings" extension, though, if it's ever
created.

* present both, but only if they _differ_, with the "printed" value
> smaller and below the "physical" value.
>

I like this idea.

>
> Astron
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Patrick Scott
Hi,
> On a side note, when fast-scrolling through artists on an iPod classic or
> contacts on an Android phone (and probably iPhone), the first letter of the
> current artists/contacts you're scrolling through is shown front and centre
> on screen in a huge transparent font. Something similar to this could be
> quite nice in LO with page numbers in Writer and Slide numbers in Impress.

Good idea, but it would look less than amazing in LibO. Currently even
even simple actions like clicking on one of the buttons in the start
centre can produce a flicker. Unless anyone really decides to rewrite
LibO in Qt or GTK/Clutter, such a feature won't make users (at least,
me) happy.


As it currently looks in the little survey, there are many of you that
will need page numbers in another place, too, not just on the document
background—because you're working in a non-maximised window (that's
what I meant by full-screen, sorry for the confusion) on often smaller
screens or use multiple pages/multiple documents at once. So I give up
on wanting to remove page numbers from the status bar.


@Mirek:
> In the original (Citrus UI) proposal, the number also serves as a page (or
> slide) handle. When you click it, you get a contextual toolbar with all the
> commands pertaining to the page [group]: page style, layout, format,
> orientation, margins, columns, borders, header, footer, etc.

I don't know, but I can't imagine this kind of behaviour when the page
numbers are not always visible. When you add a menu to the page
numbers you easily start depending on them and sometimes not seeing
the numbers will create confusion and enrage users who wonder where
the easy way of adjusting the page just went. Many probably will
assume that they'll have to zoom out again (if they don't know they
can find the same things in the (context) menu).


Astron.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Alexander Wilms Alexander Wilms
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Jean Weber
THE SURVEY:
1. What's your screen size and resolution (most of the time)?
2. What paper format do you use?
3. Do you work in full-screen?
4. Do you use any multi-page mode (for instance two pages in one screen?

My answers:
1.15,6 inch (1366 x 768)
2. A4
3. No
4. No

Alex



--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
Hi Astron,

2011/6/24 Astron <[hidden email]>

> Hi,
> > On a side note, when fast-scrolling through artists on an iPod classic or
> > contacts on an Android phone (and probably iPhone), the first letter of
> the
> > current artists/contacts you're scrolling through is shown front and
> centre
> > on screen in a huge transparent font. Something similar to this could be
> > quite nice in LO with page numbers in Writer and Slide numbers in
> Impress.
>
> Good idea, but it would look less than amazing in LibO. Currently even
> even simple actions like clicking on one of the buttons in the start
> centre can produce a flicker. Unless anyone really decides to rewrite
> LibO in Qt or GTK/Clutter, such a feature won't make users (at least,
> me) happy.
>
>
> As it currently looks in the little survey, there are many of you that
> will need page numbers in another place, too, not just on the document
> background—because you're working in a non-maximised window (that's
> what I meant by full-screen, sorry for the confusion) on often smaller
> screens or use multiple pages/multiple documents at once. So I give up
> on wanting to remove page numbers from the status bar.
>
>
> @Mirek:
> > In the original (Citrus UI) proposal, the number also serves as a page
> (or
> > slide) handle. When you click it, you get a contextual toolbar with all
> the
> > commands pertaining to the page [group]: page style, layout, format,
> > orientation, margins, columns, borders, header, footer, etc.
>
> I don't know, but I can't imagine this kind of behaviour when the page
> numbers are not always visible. When you add a menu to the page
> numbers you easily start depending on them and sometimes not seeing
> the numbers will create confusion and enrage users who wonder where
> the easy way of adjusting the page just went. Many probably will
> assume that they'll have to zoom out again (if they don't know they
> can find the same things in the (context) menu).
>

If the page number were to become a clickable handle, the user could always
scroll horizontally to see it -- no need for zooming out.

The number wouldn't be a menu, but a handle used for selecting a page
[group]. When clicked, you'd get a toolbar dedicated to the page [group],
much like when you click a picture in LibO and get the Picture toolbar.


>
>
> Astron.
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Alexander Wilms Alexander Wilms
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
Hi,

even though there were some improvements regarding gtk-integration in LO
3.4 there are still some issues like the flickering you mentioned. Are
there any plans to rewrite LO in gtk or QT as part of the UI redesign?
At least in my opinion that would be a huge improvement, make LO look
far more professional and would probably make coding the new UI easier.
How I understand it, LO is based on a "UI framework" that isn't native
on any system and has to be extended for each OS, right? Wouldn't it
also reduce coding work by simply delivering LO on Windows bundeled with
gtk like The Gimp?
What do you think?

Alex

Am 24.06.2011 12:49, schrieb Astron:

> Hi,
>> On a side note, when fast-scrolling through artists on an iPod classic or
>> contacts on an Android phone (and probably iPhone), the first letter of the
>> current artists/contacts you're scrolling through is shown front and centre
>> on screen in a huge transparent font. Something similar to this could be
>> quite nice in LO with page numbers in Writer and Slide numbers in Impress.
> Good idea, but it would look less than amazing in LibO. Currently even
> even simple actions like clicking on one of the buttons in the start
> centre can produce a flicker. Unless anyone really decides to rewrite
> LibO in Qt or GTK/Clutter, such a feature won't make users (at least,
> me) happy.
>
>
> As it currently looks in the little survey, there are many of you that
> will need page numbers in another place, too, not just on the document
> background—because you're working in a non-maximised window (that's
> what I meant by full-screen, sorry for the confusion) on often smaller
> screens or use multiple pages/multiple documents at once. So I give up
> on wanting to remove page numbers from the status bar.
>
>
> @Mirek:
>> In the original (Citrus UI) proposal, the number also serves as a page (or
>> slide) handle. When you click it, you get a contextual toolbar with all the
>> commands pertaining to the page [group]: page style, layout, format,
>> orientation, margins, columns, borders, header, footer, etc.
> I don't know, but I can't imagine this kind of behaviour when the page
> numbers are not always visible. When you add a menu to the page
> numbers you easily start depending on them and sometimes not seeing
> the numbers will create confusion and enrage users who wonder where
> the easy way of adjusting the page just went. Many probably will
> assume that they'll have to zoom out again (if they don't know they
> can find the same things in the (context) menu).
>
>
> Astron.
>



--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
aqualung aqualung
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
Astron wrote
THE SURVEY:
1. What's your screen size and resolution (most of the time)?
2. What paper format do you use?
3. Do you work in full-screen?
4. Do you use any multi-page mode (for instance two pages in one screen?
1. 1366 x 768 (15.6" screen)
2. A4
3. Sometimes
4. Very rarely

Thanks for your survey!
Jay Lozier Jay Lozier
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
On Thu, 2011-06-23 at 17:59 +0200, Astron wrote:

> Hi Phil, RGB, Mirek (I'll just post in this thread that Phil forked
> instead of the original one), hi everyone else, too (there's a little
> survey a -- please answer :) )
>
> Okay, first:
> > Incidentally, if the user displays facing pages, the page numbers will
> > need to be positioned correctly either side of the spread.
>
> That's correct. So many things one sometimes simply overlooks with UIs. I agree.
>
> Next:
> > Agree it's a good proposal to show the page number. However, if the
> > user has zoomed in or resized their window and can't see the number
> > any more, then you end up needing the page number elsewhere on the
> > screen as well, and if they can't see all of the page on the screen
> > they probably don't want to lose more space to toolbars/statusbars.
>
> It should still be displayed in the tooltip when moving the
> scrollbars. But in my view it could be removed from the status bar (I
> never found the page display useful because it's always small and out
> of one's view).
>
>
> > I would suggest that the page number floated beside the top left/right
> > corner of the *visible* page. Then when you are looking at the bottom
> > of page 2 and the top of page 3, you'd see the 2 at the top and the 3
> > beside the corner of page 3.
>
> That would make the number even more useful, but would make it also
> feel less "physical" (if that is a category that even applies to a
> number that is diplayed /beside/ a document). It might also get in the
> way, because then it wouldn't always be at the top of the page – but
> that's probably something minor as long as the number really stays put
> until a new number comes in. So yes, that's a good idea.
>
>
> > It could even float on the page with a
> > very light colour when the user can't see the document window
> > background.
>
> The page number should, in my view, hide when it's in the way. It
> would probably be possible to put the number as a watermark in the
> background of pages, but I don't like the idea too much, because it
> would confuse users unnecessarily.
> When users zoom in, the number should simply be cut off at the edges
> and scrollbars shouldn't allow to scroll in the area cut off. Before
> trying to argue for this, maybe a little survey could help:
>
>
> THE SURVEY:
> 1. What's your screen size and resolution (most of the time)?
> 2. What paper format do you use?
> 3. Do you work in full-screen?
> 4. Do you use any multi-page mode (for instance two pages in one screen?
>
>
> For me, that's:
> 1. 14" / 1440 * 900
> 2. A4 (sometimes A5 and A6)
> 3. Yes, always.
> 4. No.


For my computer

1. 19" 1280x1024
2. Us Letter (8.5"x11") - a little wider than A4 and little shorter
3. Yes
4. No, prefer using document tabs and easy access dock/bar showing open
apps.


--
Jay Lozier
[hidden email]

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Alexander Wilms
Hi,

> even though there were some improvements regarding gtk-integration in LO 3.4
> there are still some issues like the flickering you mentioned. Are there any
> plans to rewrite LO in gtk or QT as part of the UI redesign? At least in my
> opinion that would be a huge improvement, make LO look far more professional
> and would probably make coding the new UI easier.
> How I understand it, LO is based on a "UI framework" that isn't native on
> any system and has to be extended for each OS, right? Wouldn't it also
> reduce coding work by simply delivering LO on Windows bundeled with gtk like
> The Gimp?
> What do you think?

You're correct, LibreOffice is based on something custom called VCL
and the only programs that use it are LibO, Ooo, and to a lesser
amount Symphony (which is based on Ooo). It has to be extended for
each other UI toolkit it is supposed to mimic.
Sadly, switching is not as easy as bundling GTK/Qt, else it would have
surely been done already. When there is so much UI to be taken care of
as in the case of LibO this would probably equal a complete rewrite of
LibO. While in the long run this may be worthwhile, it would mean
developers wouldn't do much besides rewriting everything in the next
few years.
It also means that instead of starting LibreOffice, the Document
Foundation would have been better spent its time and energy on
developing Koffice or Abiword/Gnumeric and brought these programs to a
state in which they could compete against Openoffice.org and Microsoft
Office.

Astron.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Alexander Wilms Alexander Wilms
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

And how hard would it be to polish the gtk-integration to remove all the
flickering, black lines etc.? Firefox isn't based on native gtk either
but you can't spot any difference to a regular Gnome application. Would
it be possible to resolve these issues in a rather short period of time
compared to a complete rewrite?

Alex

Am 24.06.2011 20:40, schrieb Astron:

> Hi,
>
>> even though there were some improvements regarding gtk-integration in LO 3.4
>> there are still some issues like the flickering you mentioned. Are there any
>> plans to rewrite LO in gtk or QT as part of the UI redesign? At least in my
>> opinion that would be a huge improvement, make LO look far more professional
>> and would probably make coding the new UI easier.
>> How I understand it, LO is based on a "UI framework" that isn't native on
>> any system and has to be extended for each OS, right? Wouldn't it also
>> reduce coding work by simply delivering LO on Windows bundeled with gtk like
>> The Gimp?
>> What do you think?
> You're correct, LibreOffice is based on something custom called VCL
> and the only programs that use it are LibO, Ooo, and to a lesser
> amount Symphony (which is based on Ooo). It has to be extended for
> each other UI toolkit it is supposed to mimic.
> Sadly, switching is not as easy as bundling GTK/Qt, else it would have
> surely been done already. When there is so much UI to be taken care of
> as in the case of LibO this would probably equal a complete rewrite of
> LibO. While in the long run this may be worthwhile, it would mean
> developers wouldn't do much besides rewriting everything in the next
> few years.
> It also means that instead of starting LibreOffice, the Document
> Foundation would have been better spent its time and energy on
> developing Koffice or Abiword/Gnumeric and brought these programs to a
> state in which they could compete against Openoffice.org and Microsoft
> Office.
>
> Astron.
>



--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

Hi Alexander,

I think this is already worked on, sadly, no one took on this task for
Summer of Code this year, but since many of the Suse developers also
use Gnome, they are probably equally annoyed with the blinking as
other Linux users. It should take a lot less time to do this, but you
also get none of the benefits of a more modern toolkit.
For Firefox, this is different, as the Mozilla rendering engine is
very powerful, and the XUL language used to build interfaces is
relatively modern. Besides, there actually are little theming
differences between Firefox and native Gnome applications—combo boxes
look different and tooltips aren't rounded or transparent.

Astron.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

In reply to this post by Stefan Knorr (Astron)
Hi,

2011/6/24 Astron <[hidden email]>

> Hi,
>
> > even though there were some improvements regarding gtk-integration in LO
> 3.4
> > there are still some issues like the flickering you mentioned. Are there
> any
> > plans to rewrite LO in gtk or QT as part of the UI redesign? At least in
> my
> > opinion that would be a huge improvement, make LO look far more
> professional
> > and would probably make coding the new UI easier.
> > How I understand it, LO is based on a "UI framework" that isn't native on
> > any system and has to be extended for each OS, right? Wouldn't it also
> > reduce coding work by simply delivering LO on Windows bundeled with gtk
> like
> > The Gimp?
> > What do you think?
>
> You're correct, LibreOffice is based on something custom called VCL
> and the only programs that use it are LibO, Ooo, and to a lesser
> amount Symphony (which is based on Ooo). It has to be extended for
> each other UI toolkit it is supposed to mimic.
> Sadly, switching is not as easy as bundling GTK/Qt, else it would have
> surely been done already. When there is so much UI to be taken care of
> as in the case of LibO this would probably equal a complete rewrite of
> LibO. While in the long run this may be worthwhile, it would mean
> developers wouldn't do much besides rewriting everything in the next
> few years.
>

A few questions:
Would it really require a whole rewrite?
Would it be possible to replace VCL with Qt gradually?
Would maintaining and developing VCL really be advantageous compared to
switching to Qt? Even when we're on the verge of doing a major UI overhaul,
so a number of things will have to get rewritten anyway?

It also means that instead of starting LibreOffice, the Document
> Foundation would have been better spent its time and energy on
> developing Koffice or Abiword/Gnumeric and brought these programs to a
> state in which they could compete against Openoffice.org and Microsoft
> Office.
>

Calligra Suite (KOffice) does seem quite promising, based on what I've read
about its architecture. However, like a number of KDE applications, it
suffers from a very messy user interface and a plethora of features
awkwardly cobbled together. It'd be great if someone took it and made it
usable, but I doubt that the Document Foundation will want to do that.

I wonder, though, if maybe building on the Calligra base wouldn't have been
a better idea. After all, the suite is very modular, so most edits could be
contributed back, which would mean a lot less work for both projects. LibO
could also expand its application portfolio, if it chose to. The Calligra
base is very modern, so there would be a lot less code to cleanup (if any at
all), no Java to remove, no VCL to support and upgrade, ...

>
> Astron.
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Re: Page numbers on background

Hm...
I can't answer these questions, I am not a programmer... You might
best ask in the development list.
Using Qt is mentioned on the "Crazy Ideas" page at least:
http://wiki.documentfoundation.org/Development/Crazy_Ideas#Replace_all_interface_code_with_an_interface_using_the_Qt_widgets
Some of the things there are less crazy or even underway (like the
Java removal).
Astron.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Next » 12