from:"Mirek M."

Re: [Libreoffice-ux-advise] Request the creation of whiteboards

2014-07-08 Thread Mirek M.

Hi Jay,

2014-07-05 5:29 GMT+02:00 Jay Philips ypha...@gmail.com:

 Hi All,

 I'm currently working with the LibO QA team and i have submitted a bug
 report on the revamping of writer's print preview, which can be found at
  https://bugs.freedesktop.org/show_bug.cgi?id=80838 . It includes an
 image mockup, the customized xml file, and links to other bugs that need
 to be fixed in order for it to work correctly. Most of the work is
 simply the rearrangement of icons and adding visible text labels. The
 only difficult part to achieve is the page jumping control being taken
 from the navigator dialog, which meeks has already commented on.

 V Stuart Foote has suggested that a whiteboard should be setup for it
 and when i visited 
 https://wiki.documentfoundation.org/Design/Blueprints  it stated that i
 should contact this mailing list for the creation of a new whiteboard.
 So here i am. :)


Well, so far, we've only made whiteboards for larger projects that need to
go through a well-documented design process. If you're just proposing minor
changes to a toolbar, I'd keep it on Bugzilla.


 I am also working on a revamped standard toolbar and would like a
 whiteboard also created for it. I will be using my QA testing
 experience, along with work done by OOo's tracking data and Thibaut
 Brandscheid to come up with the new design.


There a whiteboard would be handy.
We're currently rethinking our design process -- could you read
http://nabble.documentfoundation.org/Revisiting-our-project-workflow-td4114936.html
and see if you'd be willing to go through the proposed process?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Remove the Navigator button below the scrollbar in Writer

2013-11-14 Thread Mirek M.

Hi guys,
So, first of all, the button isn't for the Navigator, but rather for the
Navigation feature, which is also a part of the Navigator's toolbar.
Given the range of scrollbar sizes, rendering the buttons completely
unusable in some cases [1], I would definitely vote for removing these
buttons from the scrollbar.
If we get a number of complaints about the feature being available only
from the Navigator, we can add it to the status bar, which at least has a
static height on all platforms. Given that it's been removed from Office
2013 without vocal complaints (it seems), I don't think there will be need
for that.

On Thu, Nov 14, 2013 at 4:01 PM, Ahmad Hussein Al-Harthi 
aalhar...@kacst.edu.sa wrote:

 In the first place, does it work? Because it doesn't
 for me! when I click on it I get the floating widget
 and when I click on any icon on that widget nothing
 happens!!


The icons in the widget ask you to choose what to navigate by. Afterwards,
you can use the navigation arrows in the scroll bar to navigate by that
element.


 I think, if it does work,  we should leave it or improve it..


Ahmad

 
 From: libreoffice-ux-advise-boun...@lists.freedesktop.org [
 libreoffice-ux-advise-boun...@lists.freedesktop.org] on behalf of bjoern [
 bjoern.michael...@canonical.com]
 Sent: Thursday, November 14, 2013 3:02 PM
 To: libreoffice-ux-advise@lists.freedesktop.org
 Cc: Samuel Mehrbrodt
 Subject: [Libreoffice-ux-advise] Remove the Navigator button below the
  scrollbar in Writer

 Hi guys,

 there is a patch to remove the navigator from the scrollbar:

  https://gerrit.libreoffice.org/#/c/6045/

 Could you guys form a good consensus on if that should be done in the first
 place or not, as that patch is block on that right now. Needs to be
 clarified
 best before 4.2 branchoff.

 Best,

 Bjoern


[1] https://bugs.freedesktop.org/show_bug.cgi?id=58748
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Carlito + Caladea

2013-10-12 Thread Mirek M.

On Sat, Oct 12, 2013 at 12:44 PM, Jean-Baptiste Faure 
jbf.fa...@sud-ouest.org wrote:

 Hi Mirek,

 Le 12/10/2013 00:53, Mirek M. a écrit :
  Hi guys,
  I hope we'll be bundling Carlito [1] and Caladea [2], Google's metric
  equivalents to Calibri and Cambria, and replacing Calibri and Cambria
  with these fonts by default.

 You missed to add the links [1] and [2]


Here they are:
[1]
http://gsdview.appspot.com/chromeos-localmirror/distfiles/crosextrafonts-carlito-20130920.tar.gz
[2]
http://gsdview.appspot.com/chromeos-localmirror/distfiles/crosextrafonts-20130214.tar.gz


 Best regards.
 JBF

 --
 Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
 ___
 Libreoffice-ux-advise mailing list
 Libreoffice-ux-advise@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] File menu thoughts ...

2013-10-11 Thread Mirek M.

On Fri, Oct 11, 2013 at 1:37 PM, Michael Meeks
michael.me...@collabora.comwrote:


 On Fri, 2013-10-11 at 12:37 +0200, Cor Nouws wrote:
  Quick queries, dangerous future ... :)

 No real urgency. However - I think we need a good design for
 integrating cloud storage into LibreOffice in a way that doesn't just
 ram more cruft  horrible interactions into the 'File' menu, and
 preferably starts to unwind the mess of things around the 'document'
 that we want to show, but don't really have many good places to put.


What kind of cloud storage integration are we talking here?
If it's e.g. Google Drive file sync, I'd suggest we do something similar to
Gnome Documents [1] using the new Start Center. Synced documents would be
shown among local documents, but with a special badge. Synchronization
would be managed from the Start Center and from a file's Properties dialog.

(Ideally, the Start Center should evolve to act as a kind of document
launcher/file manager listing all of the user's LibreOffice documents, not
unlike what you see in apps for Android/iOS. Once it's mature enough,
modules should start up with their respective sections in the Start Center
rather than with a new document.)

 I realise that I need more time ...

 Sure :-) that's fine - no-one is pulling a trigger right now.

 Looking forward to your thoughts,

 Regards,

 Michael.

 --
  michael.me...@collabora.com  , Pseudo Engineer, itinerant idiot


[1] https://wiki.gnome.org/Design/Apps/Documents
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Carlito + Caladea

2013-10-11 Thread Mirek M.

Hi guys,
I hope we'll be bundling Carlito [1] and Caladea [2], Google's metric
equivalents to Calibri and Cambria, and replacing Calibri and Cambria with
these fonts by default.

I'm also wondering whether, after a release or two with these fonts
bundled, we might be able to use them in the bundled templates instead of
Liberation Sans/Serif.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] File menu thoughts ...

2013-10-09 Thread Mirek M.

Hi Michael,

On Wed, Oct 9, 2013 at 5:57 PM, Michael Meeks
michael.me...@collabora.comwrote:

 Hi there,

 Just a quick query; I rather like the idea of turning the 'File'
 menu
 into rather a more advanced / full-screen/window way of popping up
 details about the document, and eventually providing a more intuitive
 place to anchor - document statistics, embedding of images / multimedia
 etc. as well as better ways to browse templates / cloud etc.


 Thoughts on that appreciated :-) I'd hate to commit some horrible
 heresy here UX - wise. [ And naturally, I've no immediate plans to work
 on this, but am exploring some ].


I personally would love to get rid of the need to use the menu bar and have
it hidden by default in the future (far, far future, from the looks of it),
so I'd prefer to see some work done on toolbars rather than on the menu bar.
In any case, I believe the file menu is stuck at being a text-only list,
given restrictions posed by Mac OS X (correct me if I'm wrong).

That said, we could certainly try to redesign the Properties dialog
sometime (once an interested developer shows up; right now, we're
prioritizing other things).
Cloud synchronization should be a task for the new Start Center and
template browsing should be covered by the Template dialog (which I'm still
hoping will get just a 2-level hierarchy and single-click to open).

On an unrelated note, would it be possible to have client-side decorations
(like in e.g.
http://spiceofdesign.deviantart.com/art/Writer-Concept-351501580) in
LibreOffice?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Advice on adding Smart-Art related settings

2013-10-02 Thread Mirek M.

On Wed, Oct 2, 2013 at 1:44 PM, Samuel Mehrbrodt s.mehrbr...@gmail.comwrote:

 That might be ok for now, but then the default behavior should be as it is
 now (SmartArt editable).
 If we have the not-editable Smart-Art as default, we need an easy way to
 make it editable.


I'd much rather for non-editable SmartArt to be default -- I'd rather not
let the user edit something rather than automatically wreck their document.


 Mirek, what do you think?

 Am 02.10.2013 11:35, schrieb Jacobo Aragunde Pérez:

  Everything is possible, it would just take more time :) But I must
 confess I would rather add an option at this moment so we can merge this
 improvement sooner, and keep working on it in sync with upstream. What do
 you think?


 If adding a contextual command would postpone the feature by months, I
suppose it could be in options *temporarily*. I don't care about the
placement.

I would really hate for devs to think that adding an option solves the
issue, though. Having a contextual command should be a top priority.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Advice on adding Smart-Art related settings

2013-10-02 Thread Mirek M.

Hi Miklos,

On Wed, Oct 2, 2013 at 2:44 PM, Miklos Vajna vmik...@collabora.co.ukwrote:

 Hi Jacobo,

 On Wed, Oct 02, 2013 at 11:30:31AM +0200, Jacobo Aragunde Pérez 
 jaragu...@igalia.com wrote:
  In my opinion, the default behaviour should be SmartArt becoming
  immutable on import.

 That would be a regression, I'm afraid, since by default ATM you can do
 that.


Maybe you can, but it's not clear that the SmartArt has been converted to
simple shapes, so the user can easily accidentally lose his data, and we
certainly don't want that.
The ideal solution would be to have a Convert to Shapes button in a
contextual toolbar, as mentioned earlier. That's the way e.g. Inkscape
deals with converting text to a path; it makes it clearer that some data is
lost. Is that really that much more complicated over adding an option?


  With the current one, a user can change the shapes
  but those changes won't be exported back to docx and that's confusing.

 Indeed. Read the original rationale here:

 http://lists.freedesktop.org/archives/libreoffice/2013-July/054428.html


There doesn't seem to be much in the way of rationale there.
I could only find need to discard the foreign properties on a object when
it is mutated; or work harder to determine what to do (Michael). Am I
looking in the wrong place?


 There we agreed that if the objects are modified (search for mutate),
 then these invisible properties should be dropped. (That's not the case
 ATM, but it should be this way in the long run.) That way if the user
 edits the shape, it'll be exported as a normal group shape, so the edit
 of the user is not lost.


But the original SmartArt object is lost without indication.
It needs to be clear to the user that he's losing data by editing the shape.


  Finally, maybe we should call this option SmartArt to LibreOffice
  shapes or reverse, since we are not involving Draw in this process.
  Besides, Draw exporting is already different: embedded Draw in a
  document is exported as a .emf file inside the .docx.

 Indeed, shapes or group shape (actually a SmartArt is imported as a
 group shape) would be a better description than Draw, you're right.

 Miklos

 ___
 Libreoffice-ux-advise mailing list
 Libreoffice-ux-advise@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise


___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] LO's styles are more confusing then MSO's (Was Re: some thoughts on the Sidebar)

2013-09-19 Thread Mirek M.

Hi Jean,

On Thu, Sep 19, 2013 at 7:07 AM, Jean-Francois Nifenecker 
jean-francois.nifenec...@laposte.net wrote:

 Hi Mirek,

 Le 18/09/2013 23:15, Mirek M. a écrit :
 
  Keep in mind that I
  encourage use of hard formatting for things like bold/italicize.

 OMG ! /o\

 If someone from the dev team promotes such an odd behaviour, I guess
 that trainers have a long way to go in order to make users adopt
 styles sigh


I'm not from the dev team.


 I really can't understand why LibO (and any Libresoftware office suite)
 don't emphasize on what actually make the difference with the other
 office suite(s) : a consistent set of styles (well, quite enough even
 though this may be enhanced).


I'm not against styles, but there are usability issues that need to be
solved before people can use them day-to-day. They certainly shouldn't be
forced on people.


 As an exercise, just do the following:
 1. Open Writer
 2. Insert the dummy Autotext (TEX in FR)
 3. Set a few words or single chars as bold

 Now to the question: how can you set the bolded items above to italics
 quickly and efficiently?
 Now imagine this single paragraph text is a whole 50 pages report.


As an experiment, I copied over the contents of
http://en.wikipedia.org/wiki/Plasmodium_falciparum_biology into
LibreOffice, which came to about 100 pages.
To set the bolded items to italics:
Open Find and Replace (Ctrl+H).
Click More Options, then Format
Select bold and close the Format dialog.
Click Find All.
Now you can either apply a character style or just click on Bold in the
toolbar to unbold the items, then on Italicize to italicize the items.

The dialog onlly selects hard-coded bolded items, not styled ones, which
makes it work very much as if one was using character styles, and one can
easily switch them out for such.


 - Direct formatting is evil. Styles are a blessing. And no other tool
 comes to par with LibreOffice for that matter. Let's claim it!


I wouldn't say direct formatting is evil, nor would I say that no other
tool comes to par with LibreOffice there.
Frankly, even though Google Drive allows using only 9 styles, all built-in
paragraph styles, I enjoy working with styles much more in Drive than in
LibreOffice. It all has to do with the UX side of the things, and
LibreOffice needs to work on that if it wants to convert users.


 --
 Jean-Francois Nifenecker, Bordeaux

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] some thoughts on the Sidebar

2013-09-18 Thread Mirek M.

On Wed, Sep 18, 2013 at 5:18 PM, Cor Nouws oo...@nouenoff.nl wrote:

Hi Jean-Baptiste,

Jean-Baptiste Faure wrote (10-09-13 07:54)

I do not agree with that except in the case of Calc. In Writer I work
always with the Navigator and/or the Stylist open. With the Sidebar, I
can close the Formatting toolbar and gain vertical space.

Yes, that is the idea.

I think the sidebar lacks the ability to embed whatever toolbar. For
example, in Writer, Bullets and Numbering, Table or Insert toolbars.

Looks in line with the pane wishes Mirek write about :)

Actually, no.
I'd like for the Properties panel to remain focused on properties.
As I said, the panel should supplement toolbars, not replace them. Rather
than duplicating toolbar functionality, the sidebar should strive to be as
expansive as possible and replace modal dialogs one day.

Another nice feature of the Sidebar could be to partially close it,
keeping visible only its small vertical button bar. So you could be able
to reopen the panel you need with one click. Currently, you need to
reopen the Sidebar then click the panel button.

[Thanks to Regina for answering this ;) ]

Ciao!

Cor

--
- Cor Nouws
- http://nl.libreoffice.org
- The Document Foundation Membership Committee Member
__**_
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.**freedesktop.orgLibreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/**mailman/listinfo/libreoffice-**ux-advisehttp://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] some thoughts on the Sidebar

2013-09-18 Thread Mirek M.

Hi Cor,

On Wed, Sep 18, 2013 at 5:16 PM, Cor Nouws oo...@nouenoff.nl wrote:

 Hi Mirek,

 Mirek M. wrote (09-09-13 14:46)


  I share your sentiments about the sidebar. It should definitely be
 hidden by default, as it adds minimal value in return for a bunch of
 wasted space and a less focused, messier interface. The exception to
 this would be Impress, because it already relies on the task pane for
 key functionality and the sidebar is the replacement.


 OK. And maybe, when visible in the other modules, remove some formatting
 toolbar?


I'm not sure if I said it in this post, but I look at the Properties panel
as the replacement for modal dialogs -- like the Inspector in Mac
applications. Thus I imagine it not acting as a replacement to the toolbar,
but as a supplement.
When you're writing, you want your workspace to be clean, uncluttered, so
that you can focus on the task at hand. The toolbar serves you quick
formatting options, but generally stays out of the way (at least when you
remove or streamline and move the Standard toolbar). When you happen to
need an advanced formatting option that you rarely use, that's when you
show the Properties panel. It shouldn't be on full-time (unless you refuse
to use styles and constantly have breaks for using advanced formatting
options while creating content; that's not a use case we should encourage,
though).
Since the user won't be using the panel full-time and since the Show/Hide
button for the panel should be part of the contextual toolbar itself, it
would be good to keep the toolbar visible even when the Properties panel is
shown to not disorient the user.


  My vision for the sidebar is a bit different, though.
 First and foremost, I'm hoping that the sidebar will be made modular,
 allowing the user to undock each individual panel (represented by a tab)
 from the sidebar. Keep just a single panel docked, the tab bar would
 disappear. That would mean that we'd get rid of the awful panel
 duplication we have with the Sidebar now -- there would a single
 Navigator, a single Gallery, and a single Style pane, and all of these
 could be docked/undocked at any side of the window and grouped into tabs
 as one wished. This is all standard panel behavior, btw -- if you want
 to try it, just take a look at Gimp or Inkscape. (And I believe the
 Adobe counterparts work similarly.)


 Those ideas for panel behaviour look sound to me. But less important in my
 view then the items I brought forward .. ;)


They're very important to me -- I can't stand the odd duplication we have
going on, with two Navigators, two Galleries, and two Style panes.
If you're using the Sidebar, you have to launch a separate Navigator in
case you need to use two panels at once.
And that might be hard to discover how to do, since it's not clear what
View - Navigator or the Navigator icon in the toolbar will do.


  As for the Properties panel, I'm hoping it will gain Style dropdowns
 like those in the toolbar (Kendy's working on this). I see no reason to
 fill the Properties panel with styles, though, as we already have the
 Styles panel for that.


 It would be my strong, very strong, preference to make controls for direct
 formatting hidden, far hidden, and clearly show styles in a useful way.


Despite favoring styles, I wouldn't dismiss the usefulness of
hard-formatted bold/italic/underlines -- they're much simpler to apply than
styles and they're as easy to replace (using Find and Replace).
I would love for the font picker and font size picker to be deemphasized,
though, given that these two should almost exclusively be applied through
paragraph styles.
GMail had fonts under an icon-only drop-down before its redesign. [1] Many
mobile word processors do the same [2][3] (although Drive [4] has the text
label Fonts instead of an icon).
I would love for the font picker to use an icon-only drop-down as well.
That would not only deemphasize the font picker, it would also emphasize
the style picker, which would now be the widest element in the toolbar.


  Furthermore, it's the Properties panel, so I would expect it to hold any
 and all of the object properties. That's the role dialogs play right
 now, and I'm hoping that, over time, the Properties panel will gain all
 of their functionality and replace them one by one. The advantage to
 that would be fast and easy access to this functionality, and the
 ability to see the changes happen live in the document.


 I like the idea of seeing a life preview. On the other hand, applying a
 style and hitting Ctrl-z or the undo button, or the other style when it's
 not what is wanted, isn't a big deal too.


Of course. That's what the Styles panel is for. (That said, that panel
should really use single-click for applying styles -- double-click is
unnecessarily strenuous.)


  The concept is
 basically the same as that of the Inspector window, which has long been
 used on Mac OS and is a key part of iWork.


 Cheers,
 Cor

 PS See you in Milan?


Yes, I

Re: [Libreoffice-ux-advise] some thoughts on the Sidebar

2013-09-18 Thread Mirek M.

On Wed, Sep 18, 2013 at 10:31 PM, Cor Nouws oo...@nouenoff.nl wrote:

Hi Mirek,

Mirek M. wrote (18-09-13 22:03)

OK. And maybe, when visible in the other modules, remove some
formatting toolbar?

I'm not sure if I said it in this post, but I look at the Properties
panel as the replacement for modal dialogs -- like the Inspector in Mac
applications. Thus I imagine it not acting as a replacement to the
toolbar, but as a supplement.

I understand that. But the controls on the formatting toolbar act as such
too.

Not really.
To make myself clear, this is how I see our toolbar:
http://blog.siliconpublishing.com/wp-content/uploads/2013/07/Formats1.png
And this is how I see the Properties panel:
http://wiki.openoffice.org/w/images/thumb/0/01/CH3_Format_Paragraphs_indents%26spacing.png/500px-CH3_Format_Paragraphs_indents%26spacing.png

(I'm hoping the toolbars will be streamlined once we have the overflow
menu, which is basically a cushion for those who've grown dependent on some
of the less useful parts of the toolbar.)

When you're writing, you want your workspace to be clean, uncluttered,
so that you can focus on the task at hand. The toolbar serves you quick
formatting options, but generally stays out of the way (at least when
you remove or streamline and move the Standard toolbar). When you happen
to need an advanced formatting option that you rarely use, that's when
you show the Properties panel. It shouldn't be on full-time (unless you
refuse to use styles and constantly have breaks for using advanced
formatting options while creating content; that's not a use case we
should encourage, though).
Since the user won't be using the panel full-time and since the

Won't many people have the side bar visible all the time, just as the tool
bar?

I hope not.
I'd like people to focus on writing their document, not on formatting it.

Of course, it all depends on what the defaults will be.

Show/Hide button for the panel should be part of the contextual toolbar
itself, it would be good to keep the toolbar visible even when the
Properties panel is shown to not disorient the user.

That is what I mean with my objection: it serves direct formatting :(

I don't quite understand you in this context.
I was talking about keeping the toolbar visible when the sidebar is shown.
That's also important when switching tabs in the Sidebar. It'd be strange
to suddenly show the toolbar when going from the Properties panel to the
Navigator panel, and it would shift a large portion of the chrome,
including the sidebar tabs themselves.

Those ideas for panel behaviour look sound to me. But less important
in my view then the items I brought forward .. ;)

They're very important to me -- I can't stand the odd duplication we
have going on, with two Navigators, two Galleries, and two Style panes.

I agree that it is important to solve that.
But most important is proper use of documents and formatting. Thus I would
first focus on improving the use of styles via the side bar.

In that case, the focus should be on improving the Styles panel.
See my post under the LO's styles are more confusing then MSO's (Was Re:
some thoughts on the Sidebar) ux-advise thread for pointers on that.

If you're using the Sidebar, you have to launch a separate Navigator in
case you need to use two panels at once.
And that might be hard to discover how to do, since it's not clear what
View - Navigator or the Navigator icon in the toolbar will do.

That is nothing different from now :)

Right now, we only have one Navigator (and the other dockable panes). We
don't have the sidebar, so there's no confusion.

And when we talk about our new users: let's pls offer them great style
handling :)

By the way: the styles panel is outdated, ugly, hides information and
actions...
No problem for me. But how much better could it be if the possibilities in
the side bar were used to make that modern etc.
(Just see the post of Olivier on ux-list - great idea to work out.)

Which post do you mean?

It would be my strong, very strong, preference to make controls for
direct formatting hidden, far hidden, and clearly show styles in a
useful way.

Despite favoring styles, I wouldn't dismiss the usefulness of
hard-formatted bold/italic/underlines -- they're much simpler to apply
than styles and they're as easy to replace (using Find and Replace).

We can't hide the key B and I for the users, alas ;)

I would love for the font picker and font size picker to be
deemphasized, though, given that these two should almost exclusively be
applied through paragraph styles.

Should yes. The same

Re: [Libreoffice-ux-advise] Numberic field - spin up/down behaviour

2013-09-11 Thread Mirek M.

I like the proposal.


On Wed, Sep 11, 2013 at 4:31 PM, Tomaž Vajngerl qui...@gmail.com wrote:

 Hi,

 Currently the spin up/down behaviour is to just increase or decrease
 by the spin size amount. I want to change this behaviour to round the
 value to the spin size amount when increasing or decreasing as I think
 this is something the user wants to do anyway.

 For example:

 numeric field has a value of 0.21 cm, spin size 0.1 cm

 Increasing (up) with the current implementation change the value to
 0.31 cm and increasing again to 0.41 cm. My proposed change would
 first round to 0.30 cm and then increase to 0.40 cm.

 Decreasing would change the value to 0.11 cm and again to 0.01 cm.
 The proposed change would round to 0.20 cm and then decrease to
 0.10 cm.

 What do you think about this change?

 Regards,
 Tomaž Vajngerl
 ___
 Libreoffice-ux-advise mailing list
 Libreoffice-ux-advise@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] some thoughts on the Sidebar

2013-09-09 Thread Mirek M.

Hi Cor,
I share your sentiments about the sidebar. It should definitely be hidden
by default, as it adds minimal value in return for a bunch of wasted space
and a less focused, messier interface. The exception to this would be
Impress, because it already relies on the task pane for key functionality
and the sidebar is the replacement.

My vision for the sidebar is a bit different, though.
First and foremost, I'm hoping that the sidebar will be made modular,
allowing the user to undock each individual panel (represented by a tab)
from the sidebar. Keep just a single panel docked, the tab bar would
disappear. That would mean that we'd get rid of the awful panel duplication
we have with the Sidebar now -- there would a single Navigator, a single
Gallery, and a single Style pane, and all of these could be docked/undocked
at any side of the window and grouped into tabs as one wished. This is all
standard panel behavior, btw -- if you want to try it, just take a look at
Gimp or Inkscape. (And I believe the Adobe counterparts work similarly.)

As for the Properties panel, I'm hoping it will gain Style dropdowns like
those in the toolbar (Kendy's working on this). I see no reason to fill the
Properties panel with styles, though, as we already have the Styles panel
for that.
Furthermore, it's the Properties panel, so I would expect it to hold any
and all of the object properties. That's the role dialogs play right now,
and I'm hoping that, over time, the Properties panel will gain all of their
functionality and replace them one by one. The advantage to that would be
fast and easy access to this functionality, and the ability to see the
changes happen live in the document. The concept is basically the same as
that of the Inspector window, which has long been used on Mac OS and is a
key part of iWork.

On Wed, Sep 4, 2013 at 5:33 PM, Cor Nouws oo...@nouenoff.nl wrote:

Hi all,

I took the freedom to post a blog about the subject.

http://cor4office.blogspot.nl/**2013/09/sidebar-avoiding-it-**
or-improve-it-for.htmlhttp://cor4office.blogspot.nl/2013/09/sidebar-avoiding-it-or-improve-it-for.html

Of course I skipped some details about the Sidebar that IMHO are not so
relevant for my point.

Two quotes:

So for me, two reasons to dislike the Sidebar: for eating space and
for promoting bad habits :(

it's clear that I would rather see support for the use of styles. So I
mocked up a little version with various style categories shown at the same
time.

Would appreciate your ideas :)

thanks ciao,
Cor

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Use Widget Layout for the Start Center

2013-09-06 Thread Mirek M.

Hi Emir,

On Mon, Aug 26, 2013 at 9:26 AM, Emir Yâsin SARI bitig...@me.com wrote:

 Hello,

 I'd like to point out some ideas of mine for the new start center as well,

 1. Tabs labeled All, Documents, Spreadsheets etc. would look better if
 they are located right under the window bar, currently they look like
 they've been pressed down by the Open/Templates buttons and LibreOffice
 logo area.


+1


 2. Changing the application background colour from settings change the SC
 background as well as usual, and LibreOffice logo looks bad under certain
 colours, not readable at all. Personally I am not sure if we ever need a LO
 logo for the Start Center, it just takes up space.


+1 to getting rid of the logo


 3. Info, Get Templates, Get Extensions buttons should be located on the
 lower corner, not upper. Again waste of space.


Not sure if these are relevant here as well.
Get Templates would be better off in the Template manager, Get Extensions
in the Extension manager, and it's enough to have Info, which just links to
the homepage, in the About dialog.


 4. Open/Templates buttons are very very big, and they look very alienated
 on OS X. Have no idea about the other platforms.


Ideally, these should be toolbar buttons, as in the proposal. [1]


 5. New document buttons under the tabs are also very big, they do not look
 native, and they leave very valuable space wasted on the right side of the
 buttons. Same case for the small buttons under the All Recent tab.


+1


 6. Also mentioned here before, Recent Documents are would offer more file
 manager capabilities, basic functions like longer file names, ability to
 dragdrop, a search bar, and a system right click context menu!


The long-term goal for the Start Center, at least how I envision it, is
similar to that of mobile/web applications or Apple's Document Library [2]:
have an application-specific file browser with a simple one-level folder
hierarchy with the primary function of finding and opening a file, not
managing it.

Based on that, drag-and-drop, to me, makes only sense in terms of grouping
documents into folders, in a similar way to the way folders work on the
Android or iOS homescreen or in Apple's Document Library. Did you mean that
or did you have something else in mind?
A search bar makes sense as well.
Instead of a right-click system menu, I'd prefer to reserve the right click
for selection, as is the behavior of the new kind of Windows 8 apps and the
new Gnome apps (Documents, Clocks, ...). By selecting something, the
toolbar should change to present selection-relevant commands, which is the
same as you'd expect from a right-click menu, with the advantage of being
more discoverable and touch-accessible.

Also, what exactly do you mean by Longer file names? Does the current
implementation not allow long filenames? Or do you mean showing the whole
file name no matter how long it is?

7. When a recent document is opened, window should maximise itself by
 default,  at least there should be an option to maximise the window
 automatically, a normal user would probably maximise the window area after
 opening a document.


This setting should be saved with the document. It should have nothing to
do with the Start Center.


 8. As a long term goal, it would be better to merge templates window into
 the start center.


It'd be good if these two could share as much as possible, though I'm not
100% sure they should be merged. I have no idea about the technical
aspects, though, so I don't have an educated opinion on this.

[1]
https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center#Proposal_by_Mirek2
[2] http://ia.net/blog/mountain-lions-new-file-system/
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Use Widget Layout for the Start Center

2013-09-06 Thread Mirek M.

On Mon, Aug 26, 2013 at 12:56 PM, Alexander Thurgood 
alex.thurg...@gmail.com wrote:

 Le 24/07/13 18:16, Krisztian Pinter a écrit :


 One major problem with document previews is that there are none for ODB
 files. When one works with ODT and ODB files regularly (as I do), this
 makes for one ugly startscreen, interspersed with ODT previews and Base
 app icons. Unfortunately, I do not know what could be done about this,
 other than perhaps providing a fake placeholder preview for the ODB
 documents, but I've no idea how that would work or what form it could take.


The Base tab itself could be presented as a list rather than a grid.

IMHO, it'd be great if LibreOffice could present each of its modules as
completely separate applications, regardless of the fact that it's really
just one.
Launching a module would launch the module-specific section of the Start
Center, only without tabs for the other modules. It would, in effect, be
very much like mobile apps or Apple's Document Library [1]. The advantage
of that would be being able to tweak the UI of each module based on the
content it works with.

[1] http://ia.net/blog/mountain-lions-new-file-system/
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Use Widget Layout for the Start Center

2013-09-06 Thread Mirek M.

On Fri, Sep 6, 2013 at 4:02 PM, Emir Yâsin SARI bitig...@me.com wrote:



 6 Eyl 2013 tarihinde 17:47 saatinde, Tor Lillqvist şunları yazdı:

 IMHO, it'd be great if LibreOffice could present each of its modules as
 completely separate applications,


 Hmm, that would mean LOTS of changes to our packaging and distribution on
 OS X (something for which there isn't exactly an abundance of engineering
 resources), where there now is just one app bundle, LibreOffice.app. You
 mean there would be separate LibreOfficeWriter.app, LibreOfficeCalc.app,
 etc? Where would their shared code be? (Duplicated in each app? Sure, that
 would work, but the usual suspects would whine think of the people who
 have to pay $$ per megabyte of download) How would installing such a thing
 work, if on a .dmg, dragging each .app separately to /Applications? Etc...

 I think current approach is better, it also gives a seamless interaction
 between components, like editing Calc sheets in Writer which MS Office on
 Mac cannot do, but what LibreOffice needs is separate component links, like
 the ability to put Calc or Writer separately on Dock, eliminating extra
 clicks, though I am not sure if it is possible or not. In any case it would
 require some separation of components.


Exactly. I'd like the Mac version to present modules in exactly the same
way they are presented on Linux and Windows. (To the user, they seem like
separate applications.) How that would be best done, though, I have no clue.
I know the Office:Mac installer automatically creates all the shortcuts to
the different applications, but I'm betting that that kind of installer
would require the changes you mentioned. And I have no clue how to separate
things like Exposé or the application menu.

That said, what I said earlier was targeted at Linux/Windows, where the
separation exists already, it just isn't complete.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design

2013-08-22 Thread Mirek M.

Hi Siqi,

On Sun, Aug 18, 2013 at 7:51 PM, Siqi Liu m...@siqi.fr wrote:

Hi Mirek,

Sorry for the late response. I was trying to stay focused on the Bonjour
support for Windows and now I can move on to more UI/UX improvements.

2013/8/13 Mirek M. maz...@gmail.com

Hi Siqi,

On Sun, Aug 11, 2013 at 4:06 AM, Siqi Liu m...@siqi.fr wrote:

Hello Mirek,

What's your take on the new screens? Eager to hear from you on them.

You can find them here:
http://siqi43.wordpress.com/2013/08/10/a-slightly-flattened-version-of-ios-impress-remote

I'll just go through them:
The Connection screens:
* What is the purpose of having a screen with a single button on it on
the tablet? Could you please just show the computers to connect to right
away, as I assume you do on the phone?

Yes, I basically used this screen to provide a background for the pop up
modal views. I can fire up the modal views right away and keep the orange
background only (without icon, connect button and app title, or any
suggestion on what kind of background to use? ). But in that case, there
won't be a cancel button on the server list page because we must keep the
modal view open if we don't have a button to reopen the server list page.
We are therefore forcing users to open this modal view in a sense... That's
my only concern here but I can definitely do this if it doesn't bother you.

It doesn't bother me.

* If you decide not to, please at least make it look like the Connect
button is tappable, and it would probably be good to use the whole Impress
remote icon graphic rather than a cut-out square (it makes sense in an
icon, but looks odd when there's ample room for it not to be cropped).

I think I will remove this page then, by keeping the orange background
only.

Great. :)

* The text on the PIN screen should read just like how you would say it
in real life. Try In Impress, go to Slide Show - Impress Remote and
enter the PIN [1678]. The string Waiting for validation from Impress...
isn't necessary unless it takes a long time to validate.

Well, this depends on how fast users enter the PIN code on their PCs
actually... I will remove it if it seems to be unnecessary. By Waiting I
actually mean that the app is waiting for pin pairing from users.

Ok.
I'd vote for removing it, then.

* It'd be better to not have the presentation preview page and just
start the presentation right away. The page is just an unnecessary extra
step.

Euh...but what happens when the iOS device first paired with the PC? It
starts the presentation right away without asking if the user want to start
it? And where should I put those configurations or they are unnecessary as
well? I was keeping it because 1) the Android app has it as well 2) This
gives users a chance to do some configuration and only start the
presentation when they are ready. I don't think one extra step which helps
to make sure the right presentation is running and all the config are right
in place would bother the lecturer... if you are in front of several
hundreds of people you don't want to make any mistakes ... that one extra
assurance weighs heavier than one extra tap on the screen as far as I am
concerned

Anyway my opinion might be subjective, but I really can't remove it before
changing the protocol, which needs some kind of consensus with the android
app as well.

That's odd -- when I tested Artur's Android app, it didn't show this screen
and instead jumped right into the presentation. Has that behavior changed
now?

If not, it'd be good to be consistent in this case.

The presentation screens:
* Where is the pointer button on the tablet?

There isn't one. If you touch the preview image (and the preview/next
button on the side will become transparent), you get the pointer. Since
it's large enough for users to use their pointer, it's unnecessary to add a
button for that effect. (on iPhone the Pointer button was used to show an
enlarged preview image)

I have a few concerns about this:
* Is it discoverable? How does the user discover that there is a pointer
feature?
* When we enable clickable elements on slides, how will those be activated?
I was hoping they would be tappable.

* The Options button looks way out of place on the tablet. Please at
least keep its background white or light gray.

I am such a bad designer :-P, I was trying to reproduce the black side
list like the one from this post on
thevergehttp://www.theverge.com/2013/8/15/4623016/buying-a-laptop-everything-you-need-to-know.
It was shown on the left when you scroll down to the main article. Whenever
you click on the gear, it will slide to the left a little bit and show the
popover. When the popover is dismissed, the gear will slide back to the
right. But yeah, now looking back, the coloring doesn't seem right. I will
change that.

Ok, good.

* The Pause and Clear buttons are really hard to see. Since the app
doesn't use TextKit

Re: [Libreoffice-ux-advise] [GSoC] Use Widget Layout for the Start Center

2013-08-18 Thread Mirek M.

Hi,

On Wed, Aug 14, 2013 at 11:00 AM, Jean-Baptiste Faure
jbf.fa...@sud-ouest.org wrote:

Hi,

Le 14/08/2013 08:51, Mirek M. a écrit :
On Tue, Aug 13, 2013 at 11:10 PM, Jean-Baptiste Faure
jbf.fa...@sud-ouest.org mailto:jbf.fa...@sud-ouest.org wrote:

Hi Krisztian,

Le 24/07/2013 18:16, Krisztian Pinter a écrit :
Hi all!

I'm working on this GSoC
project:

https://wiki.documentfoundation.org/Development/Gsoc/Ideas#Use_Widget_Layout_for_the_Start_Center

I just tried the first implementation of the new startcenter in the
master. It is interesting to view the recent documents but there is a
problem in the actual implementation in which it is impossible to see
the entire name of the file. Do you plan to offer different views of
the
list, like icons, detailed list and compact list?

I disagree, icons are useful even when you are not on the All tab to
distinguish between ODF, MSO files or other document formats.

AFAIK, we don't have separate icons for the various file formats right now.
However, if easy separation between these formats was something we needed,
we could simply add labels to our thumbnails instead.
This would add clutter, though, so perhaps presenting this information as a
file extension might be better.

I think thumbnails are informational if you have the possibility to zoom
temporary on a particular thumbnail to see a more detailed view. In
other cases I prefer icons and filenames.

You should use list view, then. :)

I'm not in favor of a compact list either -- if you need a list, use the
detailed list view, if you need to browse quickly, use the thumbnail
view. I realize that the compact view is much more compact, but it
doesn't seem worth the work and the UI overhead.

I agree, it was just an example of the different possible views.

In the mockup (here:
https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center)
the
filenames follow the old ms-dos 8 digit rule; am I wrong if I assume
that, today, nobody still uses that rule in the real life ? ;-)

Sorry, I left out the handling of long names from the proposal.
Given that Gnome Documents [1] uses the same layout, how about adopting
their way -- limiting the filename to two rows, and if it doesn't fit,
cutting it off about 8 characters from the end of the word, if I'm not
mistaken. You can ask Jon McCann or Jakub Steiner about the specifics,
if you'd like.

Why only 2 rows? If the files systems allow to have long filenames,
applications should not decide to nullify this functionality.

I was basing the design on that of Gnome Documents, where the reasoning is
to keep a nice layout going.
iWork and Google Drive go even further and allow one line for filenames.

Perhaps you're right, though -- maybe we should leave the file names up to
the user. Still, I'd be more comfortable limiting the name to at least 3 or
4 rows, to make sure a single file doesn't completely break the layout.

In a detailed list view, each column should be adjustable. Indeed it is
very common to have filenames longer than 30 characters and
distinguishable only by their last characters (for example when using
suffixes like _v01, _v02, etc.).

Yes -- that's why the cuttoff should leave about 8 characters at the end of
the word. (Gnome's example is Filetype icon is really a severe
an..xception.)

As the new StartCenter becomes a kind of document manager, it should be
very useful if it allowed to right-click on a document to display some
useful informations like size, pathname, last modified date, etc.

From an accessibility point of view, tooltips should be displayed in the
thumbnails view.

Tooltips with what information?
(Tooltips should show the full title if it's cut off.)

Another function which could be very useful is remove all not existent
local files from the recent files list.

This should be done automatically, not with a button.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Use Widget Layout for the Start Center

2013-08-18 Thread Mirek M.

On Sun, Aug 18, 2013 at 12:02 PM, Mirek M. maz...@gmail.com wrote:

Hi,

On Wed, Aug 14, 2013 at 11:00 AM, Jean-Baptiste Faure
jbf.fa...@sud-ouest.org wrote:

Hi,

Le 14/08/2013 08:51, Mirek M. a écrit :
On Tue, Aug 13, 2013 at 11:10 PM, Jean-Baptiste Faure
jbf.fa...@sud-ouest.org mailto:jbf.fa...@sud-ouest.org wrote:

Hi Krisztian,

Le 24/07/2013 18:16, Krisztian Pinter a écrit :
Hi all!

I'm working on this GSoC
project:

https://wiki.documentfoundation.org/Development/Gsoc/Ideas#Use_Widget_Layout_for_the_Start_Center

I just tried the first implementation of the new startcenter in the
master. It is interesting to view the recent documents but there is
a
problem in the actual implementation in which it is impossible to
see
the entire name of the file. Do you plan to offer different views
of the
list, like icons, detailed list and compact list?

I disagree, icons are useful even when you are not on the All tab to
distinguish between ODF, MSO files or other document formats.

I think thumbnails are informational if you have the possibility to zoom
temporary on a particular thumbnail to see a more detailed view. In
other cases I prefer icons and filenames.

You should use list view, then. :)

I agree, it was just an example of the different possible views.

Why only 2 rows? If the files systems allow to have long filenames,
applications should not decide to nullify this functionality.

I was basing the design on that of Gnome Documents, where the reasoning is
to keep a nice layout going.
iWork and Google Drive go even further and allow one line for filenames.

In a detailed list view, each column should be adjustable.

Forgot to comment this:
Here, again, I'd like to adopt the Gnome Documents layout, which is not
adjustable, but works well with just about any reasonable window size.
The columns are:
1) Small thumbnails
2) Titile on the first row, the author in a lighter font on the second row.
This column has maximum width.
3) File type (for us, simply ODF or DOC would do)
4) Local vs. cloud storage (not applicable for us right now)
5) Date of last edit.

That said, maybe the list view is a bit premature at this point.

Indeed it is
very common to have filenames longer than 30 characters and
distinguishable only by their last characters (for example when using
suffixes like _v01, _v02, etc.).

Yes -- that's why the cuttoff should leave about 8 characters at the end
of the word. (Gnome's example is Filetype icon is really a severe
an..xception.)

From an accessibility point of view, tooltips should be displayed in the
thumbnails view.

Tooltips with what information?
(Tooltips should show the full title if it's cut off.)

Another function which could be very useful is remove all not existent
local files from the recent files list.

This should be done automatically, not with a button.

___
Libreoffice-ux-advise mailing

Re: [Libreoffice-ux-advise] [GSoC] Use Widget Layout for the Start Center

2013-08-14 Thread Mirek M.

On Tue, Aug 13, 2013 at 11:10 PM, Jean-Baptiste Faure
jbf.fa...@sud-ouest.org wrote:

Hi Krisztian,

Le 24/07/2013 18:16, Krisztian Pinter a écrit :
Hi all!

I'm working on this GSoC
project:
https://wiki.documentfoundation.org/Development/Gsoc/Ideas#Use_Widget_Layout_for_the_Start_Center

I just tried the first implementation of the new startcenter in the
master. It is interesting to view the recent documents but there is a
problem in the actual implementation in which it is impossible to see
the entire name of the file. Do you plan to offer different views of the
list, like icons, detailed list and compact list?

My opinion on the matter:
It'd be good to keep the number of views simple.
A detailed list makes sense, but I don't see much of a point in an icon
list (thumbnails are much more informational, icons just show the file type
and are completely useless when you're not on the All tab). I'm not in
favor of a compact list either -- if you need a list, use the detailed list
view, if you need to browse quickly, use the thumbnail view. I realize that
the compact view is much more compact, but it doesn't seem worth the work
and the UI overhead.

In the mockup (here:
https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center) the
filenames follow the old ms-dos 8 digit rule; am I wrong if I assume
that, today, nobody still uses that rule in the real life ? ;-)

[1] https://wiki.gnome.org/Design/Apps/Documents#Tentative_Design
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Document Colors

2013-08-11 Thread Mirek M.

On Fri, Aug 9, 2013 at 6:22 PM, Jan Holesovsky ke...@suse.cz wrote:

 Hi Mirek,

 Mirek M. píše v Čt 08. 08. 2013 v 18:28 +0200:

  Also, if the concept of document colors wasn't clear, I mean the
  colors that are in use by the document. Using a custom color for
  something would add that color to the Document colors section, and
  removing all elements with that custom color would remove it from the
  section.
 
  Kendy, I think you told me once that the document colors are all
  listed in a single place, right?

 Not sure now, would have to look again :-)  But in general, I think what
 you have described could indeed fit an Easy Hack.

 Can you please create it in bugzilla - with this description  the
 mockup - and give me the number?  I'll try to add the code pointers
 there then.


https://bugs.freedesktop.org/show_bug.cgi?id=6799
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Document Colors

2013-08-08 Thread Mirek M.

Also, if the concept of document colors wasn't clear, I mean the colors
that are in use by the document. Using a custom color for something would
add that color to the Document colors section, and removing all elements
with that custom color would remove it from the section.

Kendy, I think you told me once that the document colors are all listed in
a single place, right?

On Thu, Aug 8, 2013 at 1:30 AM, Mirek M. maz...@gmail.com wrote:

 On Wed, Aug 7, 2013 at 4:52 PM, Jan Holesovsky ke...@suse.cz wrote:

 Hi Mirek,

 Mirek M. píše v Út 06. 08. 2013 v 15:30 +0200:

  How hard would it be to add a Document colors section below the
  color palette in the palette picker? Do you think it could qualify for
  an easy hack?

 Can you please provide a mockup / screenshot with - here we'd add
 this? :-) - I'm not sure I understand it well...


 Here's a Pencil mockup: http://ubuntuone.com/53CaLAjsvNpbTx54wZ1l9q.
 I hope it's clear enough. I used the proposed 12-column layout [1] instead
 of the current 8-column one in the mockup.


  Such a section would allow users to keep the style of a document if
  the document doesn't use LibreOffice colors, it would allow us to
  rethink our color selection, and it would be a step toward allowing
  the user to choose any custom color without having to go through the
  Options dialog.

 Sounds useful, and not too hard in general though; but need to
 understand it better...

 Thank you a lot,
 Kendy


 [1] https://bugs.freedesktop.org/show_bug.cgi?id=67653


___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design

2013-08-07 Thread Mirek M.

Hi Siqi,

On Mon, Aug 5, 2013 at 2:28 PM, Siqi Liu m...@siqi.fr wrote:

 Hi Mirek,

 Thanks for you feedbacks! I've responded inline for certain issues that
 you have pointed out.

 On Aug 5, 2013 11:45 AM, Mirek M. maz...@gmail.com wrote:
 
  Hi again,
  I was hoping someone else would comment, because I'm not well-versed in
 the iOS HIG and I don't care much for the platform. It doesn't help that
 the iOS 7 HIG is hidden behind an Apple ID login, which I don't have -- if
 you have one, take a look at the HIG [1] and the iOS 7 UI transition guide
 [2].

 Me neither, I'm fairly new to iOS dev actually ^^ I will take a look at it.

OK, good.

   Based on what I've gathered from articles, screens, and videos about
 iOS, though, here are my comments and concerns:
  * The swipe-in sidebar might not work on iOS 7 devices, as the swipe
 from the left side of the screen is used to go back. I'd recommend
 installing an iOS 7 beta to test out your app, and instead of a swipe-in
 sidebar, how about a pinch-out overview like on the Android app? As a plus,
 it won't be possible to accidentally show the sidebar when you meant to go
 to the last slide.

 Actually the swipe in sidebar is activated only by the detail button on
 the upper right corner since I don't want users to accidentally activate it
 by a swipe gesture. However I do need to swap the position of stop
 presentation button (on the left) and the detail button (on the right),
 didn't know why I placed them in wrong positions :-P

OK.

  * The style seems to be an odd combination of iOS 6 and iOS 7 styles.
 Please pick one and go with it (I would say iOS 7 is a better choice). It
 would be good to use orange as the accent color, like we do on Android.

 Ok, I will change the accent to orange throughout the app, which was green
 before.

 In terms of styling, I personally don't have any iOS 7 compatible device
 to test on so I can either test it in the iOS7 simulator (which is still in
 Dev preview) or really just customize all the iOS 6 elements to make them
 feel like iOS7...which doesn't appear to be a good choice to me...

iOS 7 simulator sounds good. Don't customize the iOS 6 elements -- that
would probably not give accurate results.

 But yes, I will investigate into how to make the design style transition
 between iOS6 based app and iOS7 based app. For now, all the customized
 elements are designed to be similar to the iOS7 because, ...let's admit it,
 the iOS6 UI is just too boring...I'm kind of struggling here as well.

 * I don't quite understand the layout slide show control pad. Why is the
 next slide shown on the left whan one gets to it by swiping to the right?
 Why is it shown at all?

 First, I did not stick to the Android app which used a coverflow to change
 between slides because it's to me a little bit trickier to change to next
 slide by swiping. It doesn't seem to be as reliable as to simply click on a
 button. With a button, users don't even need to look at the app to know if
 they have swiped to the next slide or the next next slide... It was pointed
 out by Michael M during the initial proposition period as well and that's
 also why I made two big buttons for users to reliably control the
 next/previous slide.

This would be good to test out. On the one hand, tapping is simpler, on the
other, it requires the presenter to look at the screen to hit the target
area, whereas, with swiping, the whole screen is the actionable area.
BTW, on Android, there's also the option to use volume buttons to switch
slides.

 Second, the reason I show a secondary slideshow preview is twofold: 1. It
 can be helpful for users to know what's the next slide, especially when the
 presentation is at the last slide, in which case the next slide will be
 black with a big SlideShow Finished on it 2. The screen size of iPhone is
 much narrower and shorter than most of the android devices, which makes it
 impossible to present only one slide while leaving enough space for the
 lecturer's notes and the buttons on the bottom (if we maintain the aspect
 ratio of the slideshow of course). If we want to keep aspect ratio of the
 slideshow image, it presenting two slides at the same time seems to solve
 the problem.

 [image: Images intégrées 1]

 [image: Images intégrées 2]

 However, it does make more sense to place the next slide to the right. I
 will change that soon.


Thanks. That will make more sense.

Be sure to keep the new iPhone shape in mind as well, though.


  * What does the Touch Pointer in settings do and how is it different
 from the Pointer button in slide view?

 The Touch Pointer option, when disabled, activates accelerometer based
 pointer. But if at the end of gsoc I don't have a reliable accelerometer
 based pointer, I will remove this option and makes it touch pointer only,

 The pointer button, in touch pointer mode, will display an enlarged
 current slide, which allows users to touch the desired part more
 accurately.

 [image: Images

Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design

2013-08-07 Thread Mirek M.

P. S. Could your app icon be orange, to be consistent with the Impress
branding?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Fwd: Document Colors

2013-08-07 Thread Mirek M.

On Wed, Aug 7, 2013 at 4:52 PM, Jan Holesovsky ke...@suse.cz wrote:

 Hi Mirek,

 Mirek M. píše v Út 06. 08. 2013 v 15:30 +0200:

  How hard would it be to add a Document colors section below the
  color palette in the palette picker? Do you think it could qualify for
  an easy hack?

 Can you please provide a mockup / screenshot with - here we'd add
 this? :-) - I'm not sure I understand it well...


Here's a Pencil mockup: http://ubuntuone.com/53CaLAjsvNpbTx54wZ1l9q.
I hope it's clear enough. I used the proposed 12-column layout [1] instead
of the current 8-column one in the mockup.


  Such a section would allow users to keep the style of a document if
  the document doesn't use LibreOffice colors, it would allow us to
  rethink our color selection, and it would be a step toward allowing
  the user to choose any custom color without having to go through the
  Options dialog.

 Sounds useful, and not too hard in general though; but need to
 understand it better...

 Thank you a lot,
 Kendy


 [1] https://bugs.freedesktop.org/show_bug.cgi?id=67653
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Document Colors

2013-08-06 Thread Mirek M.

Hi guys,
How hard would it be to add a Document colors section below the color
palette in the palette picker? Do you think it could qualify for an easy
hack?

Such a section would allow users to keep the style of a document if the
document doesn't use LibreOffice colors, it would allow us to rethink our
color selection, and it would be a step toward allowing the user to choose
any custom color without having to go through the Options dialog.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Shape Icons

2013-08-06 Thread Mirek M.

Hi guys,
We're in the middle of redesigning our icon set and I was wondering:
Since the shape icons in the Symbolic icon set have the same silhouette as
the ones in the Tango testing set, could someone just make a script to
automatically make the Tango testing shape icons based on the Symbolic
shape icons?

The process in Inkscape would be:
1) Take the shape and apply a linear gradient fill from #729fcf to #3465a4
from top to bottom.
2) Duplicate the shape four times.
3) Add a 4px stroke to one duplicate, which I'll call the Highlight Shape.
4) Add a 2px stroke to another duplicate, which I'll call the Outline
Shape. I'll call the other two duplicates Temporary Shape.
5) Convert the stroke of Highlight Shape and Outline Shape to a path.
6) Do an intersection of Highlight Shape with a Temporary Shape and
Outline Shape with the other Temporary Shape. I'll call the resulting
shapes Highlight and Outline respectively.
7) Duplicate Outline.
8) Do a difference of the duplicate of Outline with Highlight. We'll
call the resulting shape Highlight 2.
8) Make Outline black with 40% opacity.
9) Fill Highlight 2 with a linear gradient from white with 40% opacity to
white with 0% opacity from top to bottom.

Now, this only works for flat shapes without inner labels, but it could
still save a lot of time.
And, later, the script could be tuned for 3d shapes and shapes with labels
as well.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design

2013-08-05 Thread Mirek M.

Hi again,
I was hoping someone else would comment, because I'm not well-versed in the
iOS HIG and I don't care much for the platform. It doesn't help that the
iOS 7 HIG is hidden behind an Apple ID login, which I don't have -- if you
have one, take a look at the HIG [1] and the iOS 7 UI transition guide [2].
Based on what I've gathered from articles, screens, and videos about iOS,
though, here are my comments and concerns:
* The swipe-in sidebar might not work on iOS 7 devices, as the swipe from
the left side of the screen is used to go back. I'd recommend installing an
iOS 7 beta to test out your app, and instead of a swipe-in sidebar, how
about a pinch-out overview like on the Android app? As a plus, it won't be
possible to accidentally show the sidebar when you meant to go to the last
slide.
* The style seems to be an odd combination of iOS 6 and iOS 7 styles.
Please pick one and go with it (I would say iOS 7 is a better choice). It
would be good to use orange as the accent color, like we do on Android.
* I don't quite understand the layout slide show control pad. Why is the
next slide shown on the left whan one gets to it by swiping to the right?
Why is it shown at all?
* What does the Touch Pointer in settings do and how is it different from
the Pointer button in slide view?
* I think it's important to show the clock in the presentation control pad,
as that's the screen the presenter will be on the most.
* On the New Server page, Server Name should just read Name and it
should be below the IP address entry, as it's optional. The label below
is unnecessary.
* The Slide sidebar seems undiscoverable. Please have a button for it,
preferably in the main toolbar.
* I don't think Stop Presentation should get such prominent placement.
(After all, it's only used once, and you really don't want to tap it by
accident.) I'd suggest replacing it with a Back button, but only if the
presentation can be restored right away if the button is accidentally
tapped. If not, I'd suggest putting it in the menu.
* I don't think the slide show preview page is necessary.

BTW, what's in that menu? It'd be good to know.

[1] https://developer.apple.com/library/etc/redirect/WWDR/iOSHIG
[2]
https://developer.apple.com/library/etc/redirect/WWDR/iOSUITransitionGuide
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Use Widget Layout for the Start Center

2013-07-26 Thread Mirek M.

Hi Krisztian,

On Wed, Jul 24, 2013 at 6:16 PM, Krisztian Pinter
pin.termina...@gmail.comwrote:

Hi all!

I'm working on this GSoC project:
https://wiki.documentfoundation.org/Development/Gsoc/Ideas#Use_Widget_Layout_for_the_Start_Center

Currently, the Start Center (the start screen you get when you start
LibreOffice) is only a static bitmap, with few buttons and links. It would
be useful to present few recently used documents there (as thumbnails), and
do more fancy stuff.
See this overview and WidgetLayout to get more information about the
Widget Layout (this part is actually very similar to the above mentioned
task). Additionally, code for rendering the thumbnails will have to be
introduced, and maybe some code sharing with the new Template Manager will
be needed too.

Sounds good. I was about to say that perhaps you could try to reuse the
Template Manager's thumbnail rendering.

I've already converted the current startcenter to .ui, and it has been
merged to master, but it's still being improved. I'm currently working on
adding thumbnails for recent docs.

I'd like to request a mockup for the startcenter (with thumbnails for
recent docs), so we can make it look nice and pretty.

I started a whiteboard for it:
https://wiki.documentfoundation.org/Design/Whiteboards/Start_Center.

Kendy, my GSoC mentor, listed these points as his preference:
* Keep the buttons to start apps some way (but they could be smaller or
organized another way
* Keep the LibreOffice logo, but the other visual things (like the
shadows etc.) might go from my point of view
* Make it resizable, so that the screen size is better used (ie. no more
fixed rectangle in the middle of the screen)

I tried to incorporate these into the scope. Take a look at it and feel
free to make changes based on what you feel like doing. :)

Thanks for working on this!

Looking forward to your feedback!

All the best,
Krisztian

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] 9 LibreOffice Features You Should Avoid Using

2013-07-22 Thread Mirek M.

Hi Samuel,

On Fri, Jul 12, 2013 at 6:40 PM, Samuel Mehrbrodt s.mehrbr...@gmail.comwrote:

http://www.datamation.com/**open-source/9-libreoffice-**
features-you-should-avoid-**using.htmlhttp://www.datamation.com/open-source/9-libreoffice-features-you-should-avoid-using.html

What do you think about these? Maybe a good start to create some new
EasyHacks?

Some of them, definitely.

I'll give my thoughts on each one here:

*Heading Levels*
This should be fixed by a better default template that actually
differentiates between the last few headings and by only showing 3 headings
in the style picker by default, showing the 4th only when the 3rd is used,
the 5th only when the 4th is used, etc.
The former should be relatively easy and we'll work on it.

*Font Effects*
Blinking should be removed and documents with blinking text should render
it non-blinking, following in the footsteps of the deprecated blink tag
it was there for.
I don't mind embossed, engraved, outline, and shadow. I could imagine there
would be compatibility problems if they were removed (e.g. it would be
impossible to remove this formatting from older documents, which would be
bad).

*Justification Options*
I agree that Left is the only reasonable option here (though I'm surprised
Right isn't an option, but I suppose there's some kind of hack for RTL
languages) and I hope the other options fade into obscurity because of
their low-profile placement in the Paragraph dialog. Removing them, though,
would cause compatibility problems.

*Graphic Bullets*
I hope this feature will be removed. (There's always the option to switch
to the font-based bullets, so I'm not worried about compatibility there.)

*Tab Indentations*
Here I disagree -- tab indentations can be very useful, and using an
invisible table instead would just complicate things.

*Fill Characters in Tables of Contents*
Still an important feature, but we should redesign it so that the eye
doesn't have to move to the other end of the page -- changing the default
to position the page number before the article name would be good. Just for
inspiration, here are various ways to design a table of contents:
http://www.smashingmagazine.com/2008/07/07/table-of-contents-creative-and-beautiful-examples/
BTW, the Table of Contents dialog should really be redesigned, at least the
part where its structure is defined -- it's a usability nightmare.

*Heading and Footers Boxes and Shadows*
I'm glad this isn't a default, but I don't mind it being there, think that
there could even be good designs with boxes, and, again, I think removing
this feature would cause compatibility problems.

*The Gallery*
Should be more useful when we replace the default content.

*Backgrounds and Borders for Paragraphs and Characters*
Character background = highlighting, no? I would say highlighting's
important. Paragraph borders and background aren't as important, imho, but
could still serve a useful purpose. While the writer recommends using text
frames, there are disadvantages to that approach as well. It takes more
effort to create text frames, it removes the text from the main text body,
and text frames can't be defined with styles -- each frame has to be added
manually.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Refreshed Android Impress Remote

2013-07-20 Thread Mirek M.

Hi Artur,

On Sat, Jul 20, 2013 at 10:28 AM, Artur Dryomov artur.dryo...@gmail.comwrote:

 Hi Mirek,

 Also, could you upload some screenshots of the current work-in-progress
 version?


 Done — https://wiki.documentfoundation.org/Development/Impress/Remote_2
 Please consider that it is completely WIP, I’ll post a message here when a
 complete review will be necessary ;-)


Alright. I'll give my comments then.
On the whole, though, it seems excellent. I love how streamlined you
managed to make it.


 Siqi, who is working on the iOS version, plans to add a pointer feature.
 Do you think you could duplicate that for the Android app, for the sake of
 consistency and feature parity?


 Yep, of course. I just don’t want to create the UI which doesn’t rely on
 not-existent feature — pointer is not implemented at server-side yet.


Ok.


 Regards,
 Artur.

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design

2013-07-18 Thread Mirek M.

Hi Siqi,

On Sat, Jul 13, 2013 at 5:51 PM, Siqi Liu m...@siqi.fr wrote:

Hello all,

This summer I will be working on an iOS application which allows users to
control their slide shows right from their iOS devices. A complete proposal
and estimated timetable is available
herehttp://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/liusiqi43/1
.

I've already implemented all basic functionalities on the iOS5 with two
iterations of UI design but I would absolutely like to have some feedbacks
from you ! You can find my first set of design
herehttp://siqi43.wordpress.com/2013/07/05/first-set-of-remote-control-gui-mock-ups/and
a second iteration
herehttp://siqi43.wordpress.com/2013/07/08/a-first-functional-version-of-ios-remote-control/.
Note that the second one are screenshots from actual implementation while
the first one is a photoshoped draft.

Besides, shall I open up a whiteboard specific to this project so that we
can have more discussion there? What should I do to start it?

Here you go:
https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote_for_iOS.
Please add the scope, which will determine what people should and shouldn't
include in their design and then you can make the status Call for
Proposals, add the proposal section, and add your mockups.

Discussion shouldn't take place there, but rather on the Design team
mailing list [1] or on our weekly IRC chat [2]. Be sure to link to the
Design list thread on the whiteboard if you start one.

If you're not sure how the whiteboard should be structured, use
https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote_2 as
a guideline.

Finally, you can follow my progress on this feed:
http://siqi43.wordpress.com/category/libreoffice/feedhttp://siqi43.wordpress.com/category/gsoc-2013/feed
or
contact me on IRC (nickname: siqi)

Looking forward to your feedbacks and suggestions !

[1] http://nabble.documentfoundation.org/Design-f1935996.html
[2] https://wiki.documentfoundation.org/Design/Meetings
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSOC] iOS remote control design

2013-07-18 Thread Mirek M.

Hi Siqi,

On Thu, Jul 18, 2013 at 10:59 PM, Siqi Liu m...@siqi.fr wrote:

 Hello Mirek,

 Thank you for creating the whiteboard page! I've filled out the page
 with screenshots based on the current implementation and some
 explications accordingly.


Thanks for that.


 Let me know if further information is needed. I've also joined the IRC
 channel and I will post on the mailing list tomorrow.

 Btw, I've changed it to call for proposal but it doesn't seem to
 appear in the call for proposal list. Is that normal?


Yes, it has to be done manually. It's done now.


 Siqi


 2013/7/18 Mirek M. maz...@gmail.com:
  Hi Siqi,
 
  On Sat, Jul 13, 2013 at 5:51 PM, Siqi Liu m...@siqi.fr wrote:
 
  Hello all,
 
  This summer I will be working on an iOS application which allows users
 to
  control their slide shows right from their iOS devices. A complete
 proposal
  and estimated timetable is available here.
 
  I've already implemented all basic functionalities on the iOS5 with two
  iterations of UI design but I would absolutely like to have some
 feedbacks
  from you ! You can find my first set of design here and a second
 iteration
  here. Note that the second one are screenshots from actual
 implementation
  while the first one is a photoshoped draft.
 
  Besides, shall I open up a whiteboard specific to this project so that
 we
  can have more discussion there? What should I do to start it?
 
 
  Here you go:
 
 https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote_for_iOS
  .
  Please add the scope, which will determine what people should and
 shouldn't
  include in their design and then you can make the status Call for
  Proposals, add the proposal section, and add your mockups.
 
  Discussion shouldn't take place there, but rather on the Design team
 mailing
  list [1] or on our weekly IRC chat [2]. Be sure to link to the Design
 list
  thread on the whiteboard if you start one.
 
  If you're not sure how the whiteboard should be structured, use
  https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote_2as a
  guideline.
 
 
  Finally, you can follow my progress on this feed:
  http://siqi43.wordpress.com/category/libreoffice/feed or contact me on
 IRC
  (nickname: siqi)
 
  Looking forward to your feedbacks and suggestions !
 
 
  [1] http://nabble.documentfoundation.org/Design-f1935996.html
  [2] https://wiki.documentfoundation.org/Design/Meetings



 --
 

 Cordialement,
 Siqi LIU

 Étudiant Ingérieur, Université de Technologie de Compiègne
 Vice-Président de l'association robotique UTCoupe
 Responsable d'atelier de ClubChine

 --
   Tel. +33 7 61 16 95 83
   email: m...@siqi.fr
 --

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Refreshed Android Impress Remote

2013-07-18 Thread Mirek M.

Hi Artur,

On Thu, Jul 18, 2013 at 10:52 PM, Artur Dryomov artur.dryo...@gmail.comwrote:

 Hi Mirek,

 Thank you for the icon, you got my point. Probably it is not enough to
 just monochrome the current launcher icon :-? It would be better to put the
 icon to the two-dimensional space — I mean make it completely flat. Other
 action bar icons are following this style as well as Google Play example.

 Should I post a message to the design list now? :-)


A quick take in Inkscape: http://ubuntuone.com/2I4nq5EKhoRpg3OBiToNlS

Please do make a design list thread, though. :)


 The app is going well, all basic stuff was implemented, I hope to finish
 it next week. Let’s hope there will be no great troubles on the way.


Excellent!

Siqi, who is working on the iOS version, plans to add a pointer feature. Do
you think you could duplicate that for the Android app, for the sake of
consistency and feature parity?


 Thanks!
 Artur.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Refreshed Android Impress Remote

2013-07-18 Thread Mirek M.

Also, could you upload some screenshots of the current work-in-progress
version?

I noticed that, in your mockups, it's not indicated that one has to swipe
right/left to get to the next/previous slide. It'd be great if a little bit
of the next/previous slide was shown at the right/left side to indicate
that.

On Fri, Jul 19, 2013 at 1:31 AM, Mirek M. maz...@gmail.com wrote:

 Hi Artur,

 On Thu, Jul 18, 2013 at 10:52 PM, Artur Dryomov 
 artur.dryo...@gmail.comwrote:

 Hi Mirek,

 Thank you for the icon, you got my point. Probably it is not enough to
 just monochrome the current launcher icon :-? It would be better to put the
 icon to the two-dimensional space — I mean make it completely flat. Other
 action bar icons are following this style as well as Google Play example.

 Should I post a message to the design list now? :-)


 A quick take in Inkscape: http://ubuntuone.com/2I4nq5EKhoRpg3OBiToNlS

 Please do make a design list thread, though. :)


 The app is going well, all basic stuff was implemented, I hope to finish
 it next week. Let’s hope there will be no great troubles on the way.


 Excellent!

 Siqi, who is working on the iOS version, plans to add a pointer feature.
 Do you think you could duplicate that for the Android app, for the sake of
 consistency and feature parity?


 Thanks!
 Artur.


___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Refreshed Android Impress Remote

2013-06-12 Thread Mirek M.

Hi Artur,
I created a new whiteboard for the redesign:
https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote_2 .
The scope is based on what you wrote. Feel free to edit it.

On Tue, Jun 11, 2013 at 2:31 AM, Artur Dryomov artur.dryo...@gmail.comwrote:

Hi Mirek,

Thanks for your suggestions, they are really helpful!

Slides screen is the weakest part at moment as I mentioned at the wiki.

* I have to think about notes. They are necessary of course, but notes
representation of the current app version has one trouble. When there are
no notes for a slide user has half of the screen unused and empty. I
thought about adding a tab for notes — something like Android272’s proposal
at the wiki [1].

I prefer Astron's notes UI proposal:
https://dl.dropboxusercontent.com/u/87946285/libreoffice/impremoteuimockup.svg.

Would it be possible to see if there are notes, and if there aren't, to
just not show the note UI?

* I thought about using notifications for presentation timer, just like
Google Music does [2]. I am not a big fan of additional widgets — it will
be better to use as much as possible space for slides and do not produce a
visual noise. So I have to think about as well.

The thing is, when presenting, it's useful to see the timer at all times,
so that you can speed up or slow down based on how much time you have left.
It's too distracting to have to pull down the notification shade, look for
the LibO timer, and then pull it up again at times during the presentation
On the other hand, it's not very useful to see the presentation title,
which is why the current implementation shows the timer instead of the
title.

* I will remember to add a slide position, thanks for the tip!

Thanks!

Regards,
Artur.

[1]:
https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote#Proposal_by_Android272
[2]:
http://androidcommunity.com/google-play-music-updated-with-expandable-notifications-magazines-updated-too-20120823/

[1] https://wiki.documentfoundation.org/Design/Meetings
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Fwd: [GSoC] Refreshed Android Impress Remote

2013-06-12 Thread Mirek M.

Hi again,

On Wed, Jun 12, 2013 at 5:54 PM, Artur Dryomov artur.dryo...@gmail.comwrote:

 I prefer Astron's notes UI proposal:
 https://dl.dropboxusercontent.com/u/87946285/libreoffice/impremoteuimockup.svg
  .

 Yep, looks promising. And it is also surprising how similar it is to my
 proposal after a half a year :-)
 There is only one problem — such kind of interaction is not typical for
 Android.
 The bottom bar should be shown if there are no space for buttons at a
 single action bar above [1].
 The idea is pretty nice anyway and I like the direction.


Perhaps just have a hide/show notes button in the action bar, then?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Refreshed Android Impress Remote

2013-06-12 Thread Mirek M.

On Wed, Jun 12, 2013 at 6:37 PM, Artur Dryomov artur.dryo...@gmail.comwrote:

  Perhaps just have a hide/show notes button in the action bar, then?

 It is never too late to add another action bar button :-)

 What do you think about showing notes below a slide — just like the
 current implementation — but keep a slide vertical centered?
 This will solve a waste of space when there are no notes and will keep
 them visible if a presentation has them.


Notes below slide -- yes.
Vertically centered -- you mean something like in Astron's proposal? If so,
then yes, I agree.
BTW, remember to keep landscape mode in mind as well. There, notes should
probably be on the right-hand side.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [GSoC] Refreshed Android Impress Remote

2013-06-10 Thread Mirek M.

Hi Artur,
Looks great!

I am a bit concerned about the spartan Slide view, though. Where did the
timer go? Where did Notes go?
It would also be good to know which slide a person is on and out of how
many.

Other than that, I have some minor nitpicks with the wording and the text
size:
The heading on the connection screen should mention the network name (e.g.
Connecting to 192.168.1.10).
The code on the connection pairing screen and the heading on the fail
screen could be bigger.
Text labels could be shorter. [1]
If you don't assign a name, the address will be used. should suffice on
the Wi-Fi connection screen.
Make sure you enabled the remote control in Impress under Tools -
Options - LibreOffice Impress - General. should suffice on the
Connection Failed screen. Hopefully, Wi-Fi won't be an experimental feature
by the time the new remote version is released, and if it is, we probably
shouldn't recommend using it.
The connection pairing screen could simply read Go to Slide Show -
Impress Remote in Impress and enter the code: CODE.

Looking forward to the implementation! :)

On Mon, Jun 10, 2013 at 1:29 AM, Artur Dryomov artur.dryo...@gmail.comwrote:

 Hi All,

 This summer I am working on Android Impress Remote improvements.
 UI and UX polishing is one of my primary goals. I prepared some mockups to
 show you main concepts.


 https://wiki.documentfoundation.org/Design/Whiteboards/Impress_remote#GSoC_2013_proposal

 It would be great to hear your opinions and suggestions.
 If you do not want to flood discussion threads you can send me a private
 message.

 Regards,
 Artur.

 ___
 Libreoffice-ux-advise mailing list
 Libreoffice-ux-advise@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

 [1] http://developer.android.com/design/style/writing.html
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Change default shortcut of Redo action

2013-05-10 Thread Mirek M.

On Fri, May 10, 2013 at 11:05 PM, JorenDC joren.libreoff...@telenet.bewrote:

 Op 10-05-13 23:03, JorenDC schreef:

   I verified the behavior of other programs, and I see most of them
 (randomly: Firefox and on Linux (Mint), Adobe Reader on Windows, Twitter
 (v2.2.0) and native 'text editor' on Mac OSX, ...) uses ctrl+shift+z for a
 redo action. I found 1 application during my random search that also uses
 ctrl+y as redo: Word for Mac.

 Sorry for the noise. But off course, for Mac applications it isn't ctrl
 but cmd (Command).


Would it be possible to have both shortcuts?
We don't want to alienate people who are now using Ctrl+Y.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Button ordering can now adapt to desktop default ... in some places

2013-05-09 Thread Mirek M.

On Thu, May 9, 2013 at 5:20 PM, Stefan Knorr heinzless...@gmail.com wrote:

 Hi all,

 during the ESC call, it was discussed that some dialogues can now
 reorder their bottom [OK] [Cancel] etc. buttons to match the button
 ordering of the desktop.
 I.e., on Windows or KDE we'd have a [OK] [Cancel] row, and on
 Mac/Gnome we'd have a [Cancel] [OK] row. Personally, I think that is
 really cool!

 Unfortunately, the big wart here is the some dialogues part: if such
 an important part of our UI is inconsistent, that is really just
 asking for a lot of bug reports.
 The underlying problem is something alogn the lines that people don't
 actually read buttons (maybe the first time they use the dialogue, but
 certainly not later on) – they more or less blindly click where they
 think the affirmative action is sitting. Within the context of
 LibreOffice that used to be either the far left (horizontal button
 row) or the top (vertical button row) [1].
 So, we'd need a way to keep this consistent until almost every
 dialogue is converted to be able to use native ordering ... without
 stopping people from testing the native ordering.
 = Experimental mode for now?


Sounds good.


 Astron.


 [1] The one unfortunate exception in stable releases are the Load/Save
 dialogues – they are using the native button ordering. I think people
 recognise these as system dialogues since they look nothing like
 LibreOffice either, so it is not as huge a problem.
 ___
 Libreoffice-ux-advise mailing list
 Libreoffice-ux-advise@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Advise needed: alignment as part of clear direct formatting function

2013-05-08 Thread Mirek M.

On Thu, Apr 25, 2013 at 3:14 PM, Samuel Mehrbrodt s.mehrbr...@gmail.comwrote:

 Am 04.04.2013 14:09, schrieb Lior Kaplan:

  At the moment clear direct formatting also clears the text alignment
 back to the default which is left alignment. This is great for LTR text,
 but looks weird for RTL text. The proposed solution would be to align the
 text, upon clearing direct formatting, according to the paragraph
 directionality.


 Hi,

 Do I understand that right: When writing RTL text, the default paragraph
 style is Align left, but it's overwritten when writing in an RTL language?

 I have no experience with RTL, but wouldn't it make more sense to set all
 styles to Align right when using an RTL locale?


+1
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Allow scrolling through Slides by Mouse wheel

2013-05-06 Thread Mirek M.

Hi Sam,

On Tue, Apr 23, 2013 at 12:22 PM, Samuel Mehrbrodt s.mehrbr...@gmail.comwrote:

Hi,

can you please have a look at this feature suggestion:
https://bugs.freedesktop.org/**show_bug.cgi?id=38164https://bugs.freedesktop.org/show_bug.cgi?id=38164

It suggests to copy the behavior of PowerPoint which scrolls through the
slides with the mouse wheel (not on the sidepane only, but also the actual
edited Slide).
It would only move to the next/previous Slide, if the Slide is fully
shown. If it is zoomed, it will scroll down/up.

What do you think about that?

Personally I sometimes found it useful when looking for a specific Slide
in a huge presentation in PowerPoint, but more often it annoyed me that it
moved to another Slide when I just wanted to scroll down.

I've been an outspoken proponent of a continuous view [1] or a paginated
view [2] instead of the rigid single-slide view we have now, but if we are
to keep the current view, I would be in favor of the slide scrolling
proposal. I would, however, recommend having the same behavior for both a
zoomed-in and a fully shown slide and I would favor requiring a certain
minimum amount of overscroll to move to the next slide.
Ideally, we should have some kind of overscroll effect. I would suggest
scrolling down would gradually push the current slide screen up to reveal
the new slide screen, but darkened. Scrolling further would light it up
until it would slide into view, not scrolling further would just bounce
back to the current slide.
I haven't tried Chrome's history overscroll (it's not in the stable
version) [3], but it might work similarly.
Please tell me if I explained it adequately or if it would be doable.

[1] http://clickortap.files.wordpress.com/2011/09/float.png
[2]
http://spiceofdesign.deviantart.com/art/Presentation-Concept-284450150?q=gallery%3Aspiceofdesign%2F24489315qo=25
(not
exactly like this; imagine it more like Chrome's home screen pagination,
with the slide at the forefront and two very discreet arrows at the sides).
[3] https://plus.google.com/100132233764003563318/posts/95edkzqXENs
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Mass changes to Impress animations - related to fdo#41572

2013-05-01 Thread Mirek M.

On Wed, May 1, 2013 at 5:59 PM, Michel Renon michel.re...@free.fr wrote:

 Hi all,

 Le 28/03/2013 11:16, Thorsten Behrens a écrit :

 Michel Renon wrote:

 [...]


  With all your first answers, I started to brainstorm some ideas.
 I'll begin to mockup them in few days. I'll create a new page on the
 wiki.

  Awesome, looking forward!


 Here it is !

 https://wiki.**documentfoundation.org/**ImpressAnimationEntrancehttps://wiki.documentfoundation.org/ImpressAnimationEntrance

 There are 4 use cases and a first proposal.

 Is it ok to create a new panel (in the tasks panel) ?


Aren't entrance animations just a subset of custom animations? What about
other kinds of animations, like exit animations? Don't they deserve equal
treatment?

Except for fewer clicks, what would the new panel bring? Aren't all of the
options it contains already available via Effect Options?

I would rather opt for redesigning the current custom animation panel than
adding a new panel, especially as the task pane is overpopulated as is.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Faenza Icons

2013-04-24 Thread Mirek M.

Hi Mariano,

On Wed, Apr 24, 2013 at 3:08 PM, Mariano Gaudiners 
marianocordobar...@gmail.com wrote:

 What  license   i  must use   ?
 ¿ LGPL  version  3.0 ?
 So ,  you can use and modify  this   icons  for LibreOffice  .


For artwork, we currently prefer CC-BY-SA (or CC0/public domain).
However, it seems like the icons are derived from the Faenza theme and the
elementary theme, which both use the GPL license. Thus, the icon pack must
be GPL licensed as well. (You can't license GPL-derived works under the
LGPL.)
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Faenza Icons

2013-04-21 Thread Mirek M.

Hi Bjoern,

On Sun, Apr 21, 2013 at 5:50 PM, Bjoern Michaelsen 
bjoern.michael...@canonical.com wrote:

 Hi,

 anyone in contact with these guys?


 http://gnome-look.org/content/show.php?content=157970forumpage=0PHPSESSID=19364b75b3826103c4b57ee9be0cc55c
  http://www.youtube.com/watch?v=dwSEJ6skAig

 the theme looks really nice and I would love to see it properly upstreamed
 for 4.1.


I remember looking at the Faenza theme [1] and noting that it was GPL
licensed, which would lead to complications with our dual LGPL/MPL
licensing. The LibreOffice Faenza pack seems to be licensed under the LGPL,
though, which might make it simpler to include. However, that seems a bit
fishy to me, given that they are based on Faenza and elementary [2] icons,
both of which are GPL licensed.

Even despite the licensing problems, though, I don't feel like the Faenza
theme is complete enough (it seems that there are only a few dozen icons),
consistent enough, or quality enough (there's an odd use of red in some
icons) to be bundled with LibreOffice.
I have much higher hope for the flat icon theme [3] that we are working on.
(Right now, it's being driven by Issa, but hopefully more people will join.)

[1] http://tiheum.deviantart.com/art/Faenza-Icons-173323228
[2] http://danrabbit.deviantart.com/art/elementary-Icons-65437279
[3] https://github.com/libodesign/flat-icons
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Image Rotation in Writer

2013-04-04 Thread Mirek M.

On Thu, Apr 4, 2013 at 5:12 PM, Stefan Knorr heinzless...@gmail.com wrote:

 Hi all,

 As you might know, Writer currently does not allow to rotate images
 (unless of course you're willing to use a rather hacky extension).

 While the big goal should still be allow freely rotating images in the
 future, inquiring minds would like to know how people would feel about
 being able to rotate in 90 degree steps – since apparently implementing
 that would be a lot easier.
 Also, how would you feel about this being realised via toolbar buttons
 instead of image handles? (We already feature an image toolbar that
 allows to flip (=mirror) an image where it should be easy to add
 Rotate Right and Rotate Left buttons.)


Sounds good.
Handles would have been confusing.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Minor Design Bugs Initiative

2013-04-01 Thread Mirek M.

Hi guys,
It'd be great if we could start an initiative to tackle easy-to-fix UX
problems in LibreOffice, in the same spirit as Gnome's Every Detail Matters
[1] or Ubuntu's 100 Papercuts [2]. It could be a subset of easy hacks,
though these bugs should probably be tagged differently.
What do you think?

[1] https://live.gnome.org/EveryDetailMatters
[2] https://launchpad.net/hundredpapercuts
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Finding a UX dev

2013-04-01 Thread Mirek M.

Hi guys,
Compared to competitors, LibreOffice is lagging behind in terms of UX, and,
unfortunately, it seems like relatively little development is happening in
that area, often relegated to GSoC projects and Easy Hacks, which don't
always get picked up.

The UI is one of the most common targets of complaints about LibreOffice.
I'm certain many would be willing to pay a developer to work on UX-related
bugs full-time. We could draw up a Kickstarter campaign.

So, I'm wondering, is there a volunteer developer or a former GSoC student
who might be up to the task?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Fwd: Theme colors

2013-03-10 Thread Mirek M.

It seems like Calligra will be working on integrating themes.
Would anyone in LibreOffice like to work with them?

-- Forwarded message --
From: Jaroslaw Staniek stan...@kde.org
Date: Sun, Mar 10, 2013 at 10:43 AM
Subject: Re: Theme colors
To: Mirek M. maz...@gmail.com
Cc: Calligra Suite developers and users mailing list calligra-de...@kde.org

On 10 March 2013 01:11, Mirek M. maz...@gmail.com wrote:
 Hi Jarosław,
 I saw your blog post about themes in Calligra [1] and I'm wondering
whether
 there's any progress on that front.

 I'm a member of the LibreOffice design team, we're starting design on the
 color picker and we hope that once a willing developer shows up, we'll be
 able to hack our way to theme color support.

 [1] https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes

Hi Mirek,
Thanks for your interest. The code for Themes has not landed in
Calligra only because of not-the-highest-priority but since then I
heard encouraging comments and no disagreement so we shall finally
have them. If this fits LibreOffice plans we can co-develop the
design/specifications so we'll be compatible (e.g. we can share theme
files and properly embed them in documents/templates, staying
backward-compatible with not-theme-aware software). In addition to
defining some extensions to ODF, the specs would be in large part
related to behaviour of the applications. I also hope some relevant
functional/unit tests could be shared.

As a first step I propose a common wiki page (is there neutral one or
would you accept Calligra Wiki?)

Coincidentally we have another Calligra Sprint this weekend :)
(CC'd calligra-de...@kde.org)

--
regards / pozdrawiam, Jaroslaw Staniek
 Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] EasyHack proposals

2013-02-18 Thread Mirek M.

On Thu, Feb 7, 2013 at 1:02 PM, Mirek M. maz...@gmail.com wrote:

 Hi everyone,
 It'd be good to finally get working on LibreOffice's UI, which tends to be 
 the most criticized part of LibreOffice.
 Below are some suggestions for EasyHacks -- please respond whether they fit 
 under the scope of EasyHacks and, if so, whether you'd like to mentor any.

 Styles preview: https://bugs.freedesktop.org/show_bug.cgi?id=59718


 Borders not drawn correctly: 
 https://bugs.freedesktop.org/show_bug.cgi?id=59718

 Icon labels: https://bugs.freedesktop.org/show_bug.cgi?id=60412

 Responsive Layout: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=60414

 Page toolbar and page selection (could be split into two easyhacks): 
 https://www.libreoffice.org/bugzilla/show_bug.cgi?id=60416

Separate page toolbar bug:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=61080


 Allow navigation by hyperlink: 
 https://bugs.freedesktop.org/show_bug.cgi?id=52116

 Navigator: display hyperlinks in order of appearance: 
 https://bugs.freedesktop.org/show_bug.cgi?id=52115

 Navigation buttons can't be assigned a hotkey: 
 https://bugs.freedesktop.org/show_bug.cgi?id=51401

 I haven't had time to produce bug reports for the following, will do so soon, 
 but here are quick descriptions:

 Animation sidebar: move „Add“, „Change“, „Remove“, Play, Up, and Down 
 to an icon-based toolbar at the bottom of the animation list, remove the 
 Slide show button.

 Make the styles drop-down preview all formatting, including capitalization.

 Optional Hidden Items Menu and Style menus: described on 
 https://wiki.documentfoundation.org/User:Mirek2#UI_Hacks

Here are some additional EasyHacks, stemming from my discussion with Kendy:
Right-aligned toolbars:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=60893
Minimum width for scroll bars:
https://bugs.freedesktop.org/show_bug.cgi?id=58748
Making combo boxes into drop-down buttons:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=61004
Sizing toolbar combo boxes and dropdown buttons based on icon size:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=61005
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] EasyHack proposals

2013-02-07 Thread Mirek M.

Hi everyone,
It'd be good to finally get working on LibreOffice's UI, which tends to be
the most criticized part of LibreOffice.
Below are some suggestions for EasyHacks -- please respond whether they fit
under the scope of EasyHacks and, if so, whether you'd like to mentor any.

Styles preview: https://bugs.freedesktop.org/show_bug.cgi?id=59718

Borders not drawn correctly:
https://bugs.freedesktop.org/show_bug.cgi?id=59718

Icon labels: https://bugs.freedesktop.org/show_bug.cgi?id=60412

Responsive Layout:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=60414

Page toolbar and page selection (could be split into two easyhacks):
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=60416

Allow navigation by hyperlink:
https://bugs.freedesktop.org/show_bug.cgi?id=52116

Navigator: display hyperlinks in order of appearance:
https://bugs.freedesktop.org/show_bug.cgi?id=52115

Navigation buttons can't be assigned a hotkey:
https://bugs.freedesktop.org/show_bug.cgi?id=51401

I haven't had time to produce bug reports for the following, will do so
soon, but here are quick descriptions:

Animation sidebar: move „Add“, „Change“, „Remove“, Play, Up, and Down
to an icon-based toolbar at the bottom of the animation list, remove the
Slide show button.

Make the styles drop-down preview all formatting, including capitalization.

Optional Hidden Items Menu and Style menus: described on
https://wiki.documentfoundation.org/User:Mirek2#UI_Hacks
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Inclusion of Tango_testing icons in 4.0?

2013-01-21 Thread Mirek M.

Hi all,

On Mon, Jan 21, 2013 at 10:46 PM, Stefan Knorr heinzless...@gmail.comwrote:

 (My Opinion) I would stay conservative here and not ship it yet.


 (Other's opinions) Mirek and Alex defended the idea of additionally

shipping Tango Testing, so users could try it in stable versions, so we

could gather more feedback.


Right.
Honestly, though, it's fine with me if the icons don't get shipped in 4.0.

But I think even they wouldn't yet make it the default.


Definitely.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Theme Colors

2013-01-20 Thread Mirek M.

Hi guys,
As you may know, we've been working on redesigning the color picker.
In our design, we've been playing with the idea of a Colors in Use
section as a way to be able to pick up on the document's color scheme.
The problem with this section is that it might be troublesome and lengthy
to scan the document for colors use, and it's not really a good way to
store a document's color scheme.
However, it turns out that there's a much better solution in OOXML called
theme colors [2] [3], where a color schemes are stored within the document,
and since the number of colors and their role is fixed, it's very simple to
switch a whole document to a different color scheme.
I assume that this functionality isn't part of ODF yet, but it would be
excellent if it could get into the next version.
Is there anyone here who could push for this addition?
It's very necessary for both furthering ODF-based office suites and for
supporting OOXML files.

As an interim solution before the feature hits ODF, would it be possible to
temporarily load the theme colors as a palette upon opening a document?

[1] wiki.documentfoundation.org/Design/Whiteboards/Color Picker
[2] http://www.schemacentral.com/sc/ooxml/t-w_ST_ColorSchemeIndex.html
[3]
https://office.microsoft.com/en-us/powerpoint-help/all-about-themes-quick-styles-cell-styles-and-background-styles-HA010178624.aspx
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Writer Styles Drop-Down problem

2012-12-14 Thread Mirek M.

On Fri, Dec 14, 2012 at 5:43 PM, Jan Holesovsky ke...@suse.cz wrote:

 Hi Samuel,

 Samuel Mehrbrodt píše v Út 11. 12. 2012 v 21:46 +0100:

  please notice the following bug, it's about using white font color in
  the Styles Drop-Down [1].
 
  What is the best solution for this?
 
  [1] https://bugs.freedesktop.org/show_bug.cgi?id=58161

 Good question :-) - I see three possibilities:

 - change the font color to black should the name be unreadable
 - change the background color to black
 - use some pattern for the background when it is default

 UX guys - what does sound best to you?


I would opt for changing the background, but instead of black, how about a
shade of gray.
Here's how I would imagine it: http://ubuntuone.com/4qCSsk66C8mFTSbXFX4NOF .
I tried to keep it distinct from the way a style with white text and a
colored background would be displayed  -- hopefully, it's apparent which
one is which from the mockup.

BTW, since we're on the topic of the style drop-down, what do you think
about the suggestions at
http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.ux-advise/1295
?
Would any of the two be doable?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Template manager : feedback

2012-12-13 Thread Mirek M.

Hi Olivier,

On Thu, Dec 13, 2012 at 7:55 PM, Olivier R. olivier.nore...@gmail.comwrote:

 Hi mirek,


 mirek2 wrote
  The original idea was to not have a static size for the overlay, but
  rather
  have its size detemined by its contents

 But it was static. Only half the space was used. And I have many templates
 and it was unpractical with this tiny place.


Sure, I understand.
I'm just saying this is something that can be changed about the overlay and
it's not a reason to get rid of them altogether.


 mirek2 wrote
  , in the same way it works on
  Android (and as was designed for our Android port), and similar also to
  iOS/new Mac OS X behavior.

 Why such priority for Android? Be consistent with Android, ok, but not
 being
 consistent with the desktop is a mistake. LO is mostly a application to
 work
 on desktop. So to being consistent on PC is important too. This is still a
 productive application.


The idea is to be consistent across all platforms, including Android.

If we're talking about consistency on the desktop, things get murky,
because the file management paradigms are shifting.
Mac OS X is shifting to a new document management model and UI [1], much
like that on iOS and on Android. It's not switching to be touch-compatible
(Macs don't feature touch screens), it's switching to them because the old
model and UI is dissatisfactory.
Windows 8 and Gnome are undergoing a similar file management renaissance.
As this template manager will not change drastically in the next few years,
it makes sense to design for the new document model (which has basically
solidified on mobile operating systems and is gradually being incorporated
into desktop ones) rather than stick with the old flawed document model.


 mirek2 wrote
  It was imagined that there would only be one level of hierarchy (as is
  standard on Android and iOS), as it makes browsing templates much simpler
  and will be necessary if/when there is sync functionality between Android
  and desktop LibreOffice.

 Why limitating other users with such restrictions?
 Other users may have more than one level.


Here are a few reasons:
1) From [1]: Folders tend to grow deeper and deeper. As soon as we have
more than a handful of notions, or (beware!) more than one hierarchical
level of notions, it gets hard for most brains to build a mental model of
that information architecture. While it is common to have several hierarchy
levels in applications and file systems, they actually don’t work very
well. We are just not smart enough to deal with notional pyramids. Trying
to picture notional systems with several levels is like thinking three
moves ahead in chess. Everybody believes that they can, but only a few
skilled people really can do it. If you doubt this, prove me wrong by
telling me what is in each file menu in your browser…
2) From the same link: Folders-in-folders are hard to deal with. Just as
physical folders-in-folders are prone to creating a mess, digital
folders-in-folders represent a steep mental hurdle for most of us. Most
people don’t want to bother with folder structures. They get confused when
they’re forced to deal with settings in a text editing application. People
expect things to just work.
3) Synchronization of folders across platforms, like Android and iOS, where
single-level hierarchy is standard.

[1] http://informationarchitects.net/blog/mountain-lions-new-file-system/
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Should formatting apply to word at cursor position or only characters typed after formatting was invoked

2012-12-08 Thread Mirek M.

On Fri, Dec 7, 2012 at 2:41 PM, Daniel Mania daniel.ma...@umb.no wrote:

 Hei everyone!

 A while ago I filed a bug report and I had to realize that I am looking at
 a design choice here.
 https://bugs.freedesktop.org/**show_bug.cgi?id=46517https://bugs.freedesktop.org/show_bug.cgi?id=46517

 Basically, when the cursor resides in a word (after first or in front of
 the last character of the word), all formats apply to the whole word. I
 never realized this, until I started using subscript and superscript a lot
 in my writing (for chemical names like CO2).

 Is it feasible to change this behavior to formats only being applied to
 newly typed characters?
 It seems strange to me, that the whole word is affected, since it is
 something from the past, in contrast to typing new characters in the future
 after invoking formatting (like super-/subscript).
 If a whole word has to be formatted, it can easily be marked by double
 clicking it. This also makes more sense to me, since I thereby actively
 tell LibreOffice, that I want the whole word to be affected.
 For clarification, I am arguing for the logic behind the formatting
 behavior, not for a reduction in mouse clicks to perform a certain task.


We've discused this on today's design IRC meeting, and we agreed that, when
within a word, subscript and superscript should not apply to the whole
word, but other formatting commands should, as it's usual for a user to
want to italicize or underline a whole word, but uncommon for a whole word
to be a subscript or a superscript.

Could a developer make an exception for subscript and superscript so that
it doesn't apply to the whole word when the cursor is inside it, please?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Style dropdown suggestions

2012-12-07 Thread Mirek M.

Hi everyone,
now that we have previews in the style dropdown (thanks Kendy!), there are
two other hopefully somewhat simple tweaks that the dropdown could use.

1) Could each entry be associated with a dropdown menu, containing Modify
Based on Selection, Modify..., and Apply style, similar to Google
Docs's implementation [1]?

2) In regards to hierarchical styles (like Headings), could the dropdown
show only styles up to the outline level one up of the one used? (i.e. if
the user hasn't used any heading, show only Heading 1, if he has used
Heading 8, show all headings up to Heading 9.)

(These are tweaks we have agreed on on our design IRC chat, so feel free to
start hacking on them.)

[1]
https://clickortap.wordpress.com/2012/02/19/notice-google-docs-new-style-management/#jp-carousel-973
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] new listbox in calc options pages

2012-12-07 Thread Mirek M.

Hi Markus,

On Fri, Dec 7, 2012 at 10:35 PM, Markus Mohrhard 
markus.mohrh...@googlemail.com wrote:

 e to add another option to calc's options pages. Since this has
 to happen till Beta2 we would need quick feedback.

 Since 4.0 we are able to use the cached values written into OOXML
 files to prevent a slow recalculation when opening a file. Hoewever
 Excel and Calc don't always give the same result for formulas so we
 (Eike, Kohei and me) agreed that we need to give the user a choice
 wether to recalculate the formulas or not. This is already implemented
 in Beta1 but it is disturbing with time as it means you always have to
 click the dialog aways. The solution to it is to offer two additional
 choices in the dialog: Always and Never and respect these to prevent
 the dialog.


How about using Cedric's new infobar instead, using cached values by
default? (See the proposed specification at [1].)


 To be able to change them later they should also appear in the options
 pages with the 3 choices: Always, Ask, Never. To which Calc options
 page should we add this new listbox?


[1]
http://wiki.documentfoundation.org/Design/Whiteboards/Infobar#Proposal_by_Mirek2
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Meeting to discuss the Template manager lively?

2012-12-07 Thread Mirek M.

Hi guys,
For those that weren't present, I should mention that the decision was to
use double-click by default, adopt single-click when single-click file
management is more common.

I was wondering: Could single-click be a flag under experimental options,
so that a) it can be tested and refined for possible future use (the
selection mechanism needs some design tweaks, to make it clear that one can
click the title to select), b) single-clickers like me and tablet users
have the option to use single-click?

Also, could the blue highlight and the checkboxes be hidden by default (in
double-click mode)? They're confusing, as they make the dialog feel like
it's single-click.

Also, folder renaming doesn't seem to work yet (at least not in my 6b6783
build).

We also discussed having a separate dialog for saving templates, presenting
only a field for a name and a folder list (either a dropdown menu or a
field), with the default being no folder. It's somewhat similar to the
pop-up one would get when saving a bookmark in a web browser.
Cedric, do you need a design for that, or will you whip up something
yourself and ask for feedback?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Scrollbar size minimum

2012-12-07 Thread Mirek M.

Hi everyone,
I've been using LibreOffice under elementary OS for a while, and I've
noticed a couple of UI bugs.
The most damaging by far is that the buttons and tabs that are integrated
with the scrollbar are resized according to the system scrollbar size.
It's not that much of a problem in Writer [1], but it's a huge problem in
Calc [2] and Draw [3], at least when one has several sheets/layers.

Could there be a minimum size for the scrollbars, or, if that'd be hard to
do, could the sheet tabs and draw layers be presented on a separate line,
below the scroll bar?

[1] https://ubuntuone.com/2c4HichNKuWplCJDwWRAA5
[2] https://ubuntuone.com/21VpcXsR98olQOe4JsQAJF
[3] https://ubuntuone.com/4tkM1NLDETn09BgtKIek4n
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Meeting to discuss the Template manager lively?

2012-12-06 Thread Mirek M.

Hi everyone,
Sorry I couldn't make the chat (I'm typing this last minute at school in
class).
That said, let me at least comment on the issues raised:

On Thu, Dec 6, 2012 at 1:14 PM, Cedric Bosdonnat cbosdon...@suse.comwrote:

 Hi all,

 After having some feedback of several users in the french contributors,
 I would like to have a small chat with you to discuss the too innovative
 things of that dialog.


Did they test the dialog after you implemented single-click? (I myself have
had issues with the double-click browser.)


 First of all there is no need to think about tablet-oriented design
 since this UI will need to be written once again for the tablets.


1) All the UI decisions have good reasoning behind them for mouse users.
They're not tablet-specific.
2) When you say tablets, you mean devices that run Android and iOS.
However, that completely ignores devices with a touch screen that run
desktop operating systems, the number of which, with the introduction of
Windows 8, is rapidly increasing.


 The feedback I have:
   * Single click is not consistent with the rest of the application. Can
 be misleading for users


There is a strong case to be made against double-click [1]. Actually,
double-click is unintuitive in and of itself, and, on traditional desktop
software, it's used so inconsistently that it's just something the user has
to learn in each application (web and desktop), even though long-time users
might not think so. Fortunately, software is moving away from double-click.
But the only way to do this is iteratively, thus there must be some
inconsistencies while changing over. (GNOME 3 is undergoing the same
process.)

But rather than talk about why not double-click, here's the reason why we
should use single-click.
The primary function of the template dialog is to open an instance of a
template -- that's what it will be used for most of the time. It therefore
makes sense to associate it to the simpler, faster action, single-click.

  * Selection is not obvious


Are you sure?
The same type of selection has been tried and tested in KDE's Dolphin and
in web applications. elementary's also adopting this type of selection in
its default file browser.

  * Adding a Cancel button would be nice


It makes more sense to think of the Template manager as a standalone
dialog, much like the Start Center.
Unlike modal dialogs, the Template manager has its own purpose.
(I hope to add some more thoughts at home, no time now.)

Having innovating UI is great, but we need to keep it consistent across
 the whole application. We also need to take care of our poor users still
 sticking to old way to design ;)

 I would be in favor of:
   * Using tabs as designed by Alexander
   * Revert to single click for selection + double click for the action
   * Remove the selection mode completely (even the triggering from the
 right click)
   * Add the Cancel button at least for the Save As Template case.

 For a meeting, I can easily manage to find time during office hours, but
 outside it starts to be difficult. What about right after ESC today?

 Regards,
 --
 Cedric


[1] http://www.codinghorror.com/blog/2004/10/double-click-must-die.html
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Default Styles in Writer

2012-11-26 Thread Mirek M.

On Sun, Nov 25, 2012 at 1:06 PM, Olivier Hallot 
olivier.hal...@documentfoundation.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 HI

 Em 25-11-2012 07:05, Olivier R. escreveu:
  Hi *,
 
 
  Jan Holesovsky wrote
  And - being at the HackFest in Munich, I've just managed to get the
  previews of the styles working:
 
 
 http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/permalinks/2012-11-24T21_03_58.html


Awesome!


 
  This is cool. :)
  Is it possible to get this feature in the stylist ?


+1

  A long time ago, I had made a mock-up for Cédric.
  http://wiki.documentfoundation.org/File:NewStylist.png


 
  Regards,
  Olivier

 Adding the cherry on top of the cake:

 Allow to drag the style entry from the Stylist and drop into the text to
 apply the style (slight improvemento to the current double click on the
 style)


Drag and drop is a longer and more complex action than double-click.
Why not just apply a style on single-click, same as in the style drop-down?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Input about Options WAS Re: Need Developer Input about Options

2012-11-09 Thread Mirek M.

Hi Cor, and sorry for taking so long to respond.
This response is preliminary anyway, as our IRC meeting should be the place
where we make these decisions, so take it with a grain of salt.

On Mon, Nov 5, 2012 at 4:52 PM, Cor Nouws oo...@nouenoff.nl wrote:

 Mirek M. wrote (02-11-12 01:21)

 On Fri, Nov 2, 2012 at 12:03 AM, Cor Nouws oo...@nouenoff.nl
 mailto:oo...@nouenoff.nl wrote:


  http://wiki.**documentfoundation.org/Design/**
 Analyses/Global_Optionshttp://wiki.documentfoundation.org/Design/Analyses/Global_Options
 

 Is it OK if I add some opinions on that page (again)?


 Post them here. :)


 Well, here we go (I've skipped the ones that are mentioned earlier in this
 thread, and those that I've no opinion/knowledge).


 - Other user data
 I would keep this with the other (First Name, Last Name) so 'Generic'


Alright.
Even fax?


 - Help Agent
 I would go for 'Generic'


Are you sure?
The help agent is kind of a bad copy of Clippy, and has been shown to be
annoying rather than helpful.


 - Number of Undo Steps'Unnecessary'
 Interferers with memory usage which is an area with sometimes problems
 (I've noticed on certain citrix installations)
 So I would go for 'Advanced'.


Ok.


 - Icons in Menus'Unnecessary'
 It definitely can add to learning, if icons from toolbars are visible in
 the menu too (and also I find it nice to see).
 I would go for 'Generic'


It's always preferable to have one good default instead of yet another
option.
The original decision was to use the OS default, which is usually the best
way to go, but now I can see how icons in menu bars can increase usability
quite a bit, so I would default to that instead, and put the option to turn
them off under Advanced.
(Hopefully we'll discuss this on our IRC chat.)


 - Show preview of fonts / Show font history
 'Unnecessary' (Always enabled)
 Fine for me, as the tech guys confirm that there are no technical reasons
 for that (in certain circumstances)be


Good


 - Graphics Output
   Use hardware acceleration and Use Anti-Aliasing
 are in the same category for me: to watch for with certain use.


Can you elaborate?


 Having them available in one place is more logic to me.

 - Selection
   Transparency (level) 'Unnecessary'
 Ah well, it looks nice, so pls lets keep it!


Heh, you're right -- I don't know what I was thinking when we made this
decision.

I agree that the inverse option looks bad, and, in some cases, makes it
hard to see the selected text.
Transparency level is a bit of an overkill -- I'd at least get rid of
that.
Are there any issues with having Transparency always enabled, though
(besides on high-contrast themes, where the default should be inverse)?

Also, what prevents us from using the system default?


 -  Print / Reduce Print Data
 All contextual Yes, but I know where those are set per company policy.
 So as 'Generic' setting ...


Alright.


 - Paths / Templates
 I would say 'Advanced'


Ok.


 -  Online Update
 I would say 'Generic' for sure!


We were deciding between Contextual and Generic, as a while back a person
contacted us about putting update functionality into the About dialog. He
hasn't worked on it, so we're free to make the decision.

I agree Generic would be best.


 - Load / Load user-specific settings with the document
 I would say 'Advanced'


Alright.


 - Warn when not saving in ODF or default format   ' Advanced'
 I would keep this with the other (Default file format) so 'Generic'


It'd be nice to get rid of this option altogether.
It would be best to separate out cases where formatting is preserved and
where it is lost. For the former, a simple warning in the Save as dialog
should suffice. For the latter, it would be best to use a modal dialog both
after saving and saving as.


 - Spellcheck / Hypnenation
 I would say 'Generic' for all those...

 Alright.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [Writer] Header/footer deletion from the UI

2012-10-28 Thread Mirek M.

On Sun, Oct 28, 2012 at 9:18 AM, Jean-Francois Nifenecker 
jean-francois.nifenec...@laposte.net wrote:

 If I ask to delete an existing header using the Header button, I'm
 receiving a confirmation dialog informing that the header contents will be
 lost.

 I feel that this behaviour is interfeering with the user workflow. IMO,
 the header deletion should be immediate (if the users asks for that, of
 course he knows that the contents will disappear!) so that the user can
 continue working on his document. But, of course, this operation should be
 undoable (which it is not currently).


+1
Anyone want to work on making header/footer deletion undoable?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Rename Slide Design

2012-10-25 Thread Mirek M.


 On Thu, Oct 25, 2012 at 6:45 AM, Olivier Hallot 
 olivier.hal...@documentfoundation.org wrote:


 I already did that when I translated to pt-BR, so it is OK for me.


:) great


 We only have to enphasize the difference between presentation template
 and slide template - no you or me, or any knowledgeable LO user - but
 average user may get confused by these templates.


Well, our users (including me) are already confused by the Slide Design
title.
On Google+, Sebastian Spaeth wrote: if there were one thing I could change
in impress, it would be renamin slide design. I can never remember what
sslide design' and what slide layout does. desin lets you choose a
template, so it would help if I had slide template vs 'slide layout'.

If you think Slide Template is too confusing, how about Slide Master
Page?

BTW, Undo calls the feature Apply presentation layout -- that should be
changed to Apply Slide Master Page as well.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Rename Slide Design

2012-10-25 Thread Mirek M.

On Thu, Oct 25, 2012 at 9:58 PM, Olivier Hallot 
olivier.hal...@documentfoundation.org wrote:

 Hi Mirek

 Em 25-10-2012 17:29, Mirek M. escreveu:
  If you think Slide Template is too confusing, how about Slide Master
  Page?
 That one is also confusing, but I have no suggestion. :-(


Well, based on my experience, people know what a template is, so I wouldn't
think there would be much of a problem.
There's really not much difference between presentation templates and slide
templates -- in fact, the function of the dialog is to take templates and
extract Master pages from them, I believe. These Masters can then be
applied to the whole presentation using a less than intuitive Exchange
background page checkbox. (This should really become an Apply to All
Slides button instead.)

It's certainly less confusing than Slide Design, which sounds like it
would include slide background (which is in Page setup) and perhaps
layouts as well.

Master Page is a less commonly-known term, and, to be honest, I really
don't like it. (A template is a model for creating objects, and that
translates well into computer terms, but a master is a person who has
control over someone/thing, and I think that hardly translates into slide
background + text formatting.) However, it might be a more accurate
description of the feature.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] InfoBars: problem when stacking too many of those

2012-10-15 Thread Mirek M.

On Mon, Oct 15, 2012 at 9:42 AM, Cedric Bosdonnat cbosdon...@suse.comwrote:

 Hi Astron, Mirek,

 Thanks for your remarks and ideas. I have to admit that Mirek's idea
 looks nice to me as it means less work ;)

 I would just raise another question. Is it a good thing to have the
 color of the info bar configurable in the Appearance options page? I
 already have that implemented, but there is a tiny problem still to be
 fixed: the info bar is not repainted when changing the color in the
 options.


It'd be preferable not to have the color configurable -- the Options dialog
is brimming over with options as is and adding an infobar color option,
which isn't really needed, would only exacerbate the matter. In our global
options analysis [1], we've decided to move appearance options out of the
main options dialog.

However, LibreOffice should be able to detect a high-contrast theme and
color the infobar and its contents accordingly.

[1]
http://wiki.documentfoundation.org/Design/Analyses/Global_Options#Appearance
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] InfoBars: problem when stacking too many of those

2012-10-15 Thread Mirek M.

On Mon, Oct 15, 2012 at 4:18 PM, Cedric Bosdonnat cbosdon...@suse.comwrote:

 On Mon, 2012-10-15 at 16:05 +0200, Stefan Knorr (Astron) wrote:
  Hi Cedric
 
   It'd be preferable not to have the color configurable -- the Options
 
  I agree with that to about 75%. I.e. it should not be
  user-configurable, but if it would adapt to GTK+/Qt themes and the
  like, that'd be great.
  I know that makes it harder, but I hope you see some point in trying
  to be a good platform citizen.

 Indeed, I'll need to investigate how to do that, since I currently don't
 know at all :)


AFAIK only GTK+ features an infobar element [1], while Qt doesn't.

[1] http://developer.gnome.org/gtkmm-tutorial/3.2/sec-infobar.html.en
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] InfoBars: problem when stacking too many of those

2012-10-12 Thread Mirek M.

Hi Astron, Cedric, everyone,

On Thu, Oct 11, 2012 at 3:33 PM, Stefan Knorr heinzless...@gmail.comwrote:

 Hello all,

 the following is just an idea of mine (yes, the discussion is ~over, I
 know):
 In general, I agree with Mirek's stance of don't overuse the info
 bars. Still, to cover some more possible cases:
 How about overlaying all infobars on top of each other, but push every
 subsequent infobar ~2 pixels down and make it a bit darker (or lighter).
 This way, you should easily be able to fit a few bars in the average
 window without it looking too ugly. If there are any more than three
 bars, you could show a counter, something like (4) or so.
 To see all bars, one could go either of two ways:

 * Create a hover effect where when the mouse hovers over the bars, they
 all automatically expand (might not be a good idea, given how we killed
 two hover features since two 3.6.0 already)


I would oppose this on the basis of ux-error-prevention. Moving targets are
rarely good.
Also, since the bars would expand anyway, it wouldn't really solve the
problem of having too many infobars in one window.


 * Let the user scroll through the info bars with the mouse wheel/touch
 scrolling


I would oppose this as well: not everyone can scroll. (I've seen various
touchpads where scrolling is pretty hard, and touchpad scrolling itself is
not very discoverable.)
Also, that the user should scroll would be undiscoverable itself.


 Additionally, we might indeed want to use colour to discriminate between
 different types of notifications. Your document is unreadable and
 Printing ... should definitely have different importances. Likewise,
 we could push more grave notifications above less grave ones.


Here I can only speak for my proposal, but infobars are not notifications
per se.
They're more like problem-solvers. They're there not to just inform you
that there's a problem, they're there to help you fix it, either by
offering a remedy right away (but, as the remedy has some side-effects, it
needs to ask the user first, as per ux-control) or at least by giving you
the necessary info to fix it.

Thus Printing... should never be an infobar, it should be shown in the
status bar or, preferably, handled by the OS itself.

There should be no grave and non-grave infobars. Each one should be
there in case of a problem. In case of a serious problem, where the user is
unable to work with the document or when editing would lead to data loss, a
modal dialog should be used instead.

Thus Your document is unreadable should not be an infobar either.


 Lastly, for notifications the user really needs to see, we could think
 about an elevation scheme when there are too many bars already, i.e. the
 normally non-modal alert would become a normal modal window. (Of course,
 this somewhat bears the question if there really should ever be a
 modeless notification that users have to answer.)


As said above: the infobar is for problems that don't prevent the user from
editing the document without data loss, yet for which an automated solution
could cause harm to the user, his data, or would counter what the user is
trying to do.
Infobars can be safely ignored or dismissed, but acting on them should
improve the UX.

Anyway, I stand by my previous post.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] New Template Dialog on Mac OSX

2012-10-08 Thread Mirek M.

Hi Alex,

On Mon, Oct 8, 2012 at 9:24 AM, Alexander Thurgood
alex.thurg...@gmail.comwrote:

 Hi all,

 So, I've just got around to looking at this on Mac OSX (sorry about
 that, but getting a debug build takes forever) and have a few questions
 / remarks :

 (1) why is there no Back button or arrow ?

 What I mean by this is that when a user clicks on a category of
 templates, at least on OSX, he/she has no way of navigating back to the
 upper hierarchy via a simple back button, indeed as is standard in the
 OSX HMI which uses the Finder dialogs for this sort of thing. Even the
 old template manager dialog had one.


AFAIK, the new OS X file management uses no back button as well. [1]
Instead, clicking a folder expands it and clicking away folds it back.
The folders in the template dialog should work somewhat similarly --
clicking away or clicking X should dismiss a folder overlay and return
back to the upper hierarchy.


 (2) one can not use the scroll arrows to scroll down the list of
 template entries in any given category - trying to do so just results in
 the upper main category buttons being commuted selectively from left to
 right or right to left depending on which scroll arrow key is pressed.
 The user has to use the mouse or touchpad to scroll down.

 (3) for some reason, the collection of templates in any given
 sub-category is displayed as two overlaid transparent examples of the
 templates in that category, perhaps the first and the last, I don't
 know, but the fact that they are overlaid each other in a transparency
 mode doesn't make it at all obvious what exactly is being represented
 and does not look particularly good (but maybe that's just a matter of
 personal taste, like so many GUI things) - is it supposed to be like this ?


I would say that's partly my fault for not devoting time to designing a
folder. (The original design was a non-transparent stack [2], but I agree
we could do much better.)
Rafael, would you be willing to implement a different look for a folder if
we designed it?


 I also managed to get OSX to crash when attempting to use the scroll
 arrow keys, but will have to see if this a one-off, or reproducible.


 In terms of OSX HMI design this will not do anything to increase LO's
 popularity on that platform, in fact I believe you will be more likely
 to drive people away with stuff like this. What, if any, further feature
 development is planned ? I realise that a lot of work went into this and
 am grateful for that, but when re-thinking UI design, please spare a
 thought for all of the OSes for which LO is built and provided.

 Alex


P.S. Could you post a screenshot?

[1]
http://cdn-static.cnet.co.uk/i/c/rv/e/software/apple/mountain-lion/mountain-lion-icloud-document-library.jpg
[2] http://wiki.documentfoundation.org/images/e/e8/Templs.png
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] New Template Dialog on Mac OSX

2012-10-08 Thread Mirek M.

On Mon, Oct 8, 2012 at 10:23 AM, Alexander Thurgood alex.thurg...@gmail.com
 wrote:

 Le 08/10/12 09:50, Mirek M. a écrit :

 Hi Mirek,

 
  AFAIK, the new OS X file management uses no back button as well. [1]
  Instead, clicking a folder expands it and clicking away folds it back.
  The folders in the template dialog should work somewhat similarly --
  clicking away or clicking X should dismiss a folder overlay and return
  back to the upper hierarchy.

 No clicking on a folder doesn't expand it by default, at least not on
 OSX 10.8, unless that folder is in the Dock. It certainly doesn't have
 that behaviour on the Desktop, or in the Finder.

 The behaviour you identified in your first link is Coverflow-related
 whic LO doesn't support in its dialogs (or if it does, I don't see how
 to activate it). Now, if you could get the dialog to do that it would
 look much nicer indeed ! :-))


Actually, it's not Coverflow-related, it's just Mac OS's new Document
Library [1], [2]. It's one of those things Apple brought from iOS to Mac
OS, so it appears in new applications and Launchpad, but doesn't appear in
Finder or in the dock.


 In fact, both of the links you provided are a vast improvement on what
 is currently displayed.


You can see the original tentative design at
http://wiki.documentfoundation.org/Design/Templates_and_documents_rework.
The screenshot you posted does look different from the design -- hopefully
those are just some design glitches that will be sorted out at the end.
Rafael, would you like to comment on that?
Also, did you receive the icons for the dialog from Astron?

[1] http://informationarchitects.net/blog/mountain-lions-new-file-system/
[2] https://www.youtube.com/watch?v=YrmZbTZwoeAfeature=player_embedded at
0:54
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Advice required on auto text resize (Impress)

2012-10-07 Thread Mirek M.

On Sat, Oct 6, 2012 at 7:55 PM, Jean-Baptiste Faure jbf.fa...@sud-ouest.org
 wrote:

 Le 03/10/2012 13:19, Muthu Subramanian K a écrit :
  Hi all,
 
  Context:
  Currently the text font size box in the toolbar displays the
  originally set font size even when the font size is reduced because of
  'Auto fit'
 I think this autofit feature is very disturbing if you are not aware of
 it. From my point of view it should be removed because if what you are
 writing does not fit in the available room, you should write less words
 or add room (split the text on another slide), but not write smaller
 when what you are writing is intended to be viewed on a projection screen.


+1


 At least autofit should not be activated by default.


+1

  One of our users requested the behavior where the text font size is
  changed when the autofit size changes the text size.
 I agree.


+1
Also, if we have to keep autofit, it should be disabled for an object if
the user overwrites the autofit size using the font size picker.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] InfoBars: problem when stacking too many of those

2012-10-04 Thread Mirek M.

Hi Cedric,

On Thu, Oct 4, 2012 at 4:13 PM, Cedric Bosdonnat cbosdon...@suse.comwrote:

 Hello!

 I'm currently starting to implement the InfoBars as I'll need them for
 the CMIS integration work. After some tests with stacked info bars, I
 figured out that we may want to specify what to do when we have too many
 of them (see attached screenshot).

 Any idea? limit them to a maximum of stacked info bars at the same time?
 hide the old one automatically? anything else?

 Note that it may not happen too often to have that many bars... but who
 knows ;)


I deliberately left this scenario out of my proposal [1], because:
a) If some infobars are hidden, it means the user is not made aware of some
problems. All info bars should have similar importance, and thus it's not
good to hide some and show some.
b) LibreOffice developers should take care not to overuse infobars. They
should also be careful to use them only to offer possible remedies to
document-related problems, or at least to give information about them so
that the user can remedy them himself.
c) If there are so many issues with a document that there's a flood of
infobars, then the user should probably react to at least some of them. If
he doesn't want to, he can always dismiss them.

[1] http://wiki.documentfoundation.org/Design/Whiteboards/Infobar
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter

2012-09-27 Thread Mirek M.

Hi Michel, everyone,

On Thu, Sep 27, 2012 at 6:04 PM, Michel Renon michel.re...@free.fr wrote:

Hi,

Le 27/09/12 09:47, Mirek M. a écrit :

[...]

If you're afraid about the lack of association between the slide pane
and the toolbar, which should sit right below it, I suppose we could tie
the toolbar to the slide pane, similarly to the Navigator and the Styles
dialog, only with the toolbar on the bottom.

Just FYI, I already proposed something equivalent... in 2009 ;-)
http://wiki.openoffice.org/w/**images/2/26/Proposal_impress_**
ui_renon3.pdfhttp://wiki.openoffice.org/w/images/2/26/Proposal_impress_ui_renon3.pdf
see part 4.3.11, page 35.
Its was my draft proposal for Renaissance project, in may 2009
(http://wiki.openoffice.org/**wiki/Proposal_by_Michel_Renonhttp://wiki.openoffice.org/wiki/Proposal_by_Michel_Renon
)

That document is incomplete, may be outdated, may contain
errors/inconsistencies, but it was imagined and written during some few
nights (and I was *very* busy at my dayjob).
Well, I should finish it an update it with new ideas I had
since...(specially ideas to remove the tab to select Impress view modes)
and try to prototype it.

We've agreed to evolve LibreOffice over time, so that means no big bang
changes.
You're still free to prototype, of course, but I hope you understand that
it's unlikely that your proposal will be implemented in whole.

As for the button bar, it seems that we all have very different ideas about
how to solve the problem and we should be careful not to end up with an
endless argument.
The decision, of course, rests with Kendy. However, if he allows, we could
do a very quick whiteboard, with the call for proposals on Friday and then
analysis and tentative design on the IRC chat.

Kendy, what do you think?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter

2012-09-26 Thread Mirek M.

Hi Michel,

On Wed, Sep 26, 2012 at 1:45 PM, Michel Renon michel.re...@free.fr wrote:

 Hi Cor, Jan,

 Le 25/09/12 16:00, Jan Holesovsky a écrit :

   [...]

  Therefore the good OpenOffice.org developers and people conducted a
 large project some years ago, Renaissance.
 Of course the toolbar is one of the changes the was a result from that.
 I guess all the work was done, because many obvious actions are not easy
 enough accessible for Joe-average. And that these were only the first
 steps in a route to make Impress (more) more contemporary.
 The little pop-ups fit more in modern UI (-expectations) I guess then
 context menu's - let alone short-cuts and pull down menus...


 I don't think I agree with you here.  The touch-based devices need to
 have everything shown, nothing appearing based on a presence of a mouse
 pointer;


 It's a technical fact : touch interfaces have no 'hover' event.
 But look at what's happening with Nautilus : devs are making big changes
 to prepare for touch interface. The mistake is that they change *current*
 desktop version so that *future* versions may work on tablets.
 Since last year, users just can see Nautilus has less and less behaviors.
 Devs just say we know what's good for you : we'll bring them back later
 for touch.
 The result is that the Nautilus project is forked and will be replaced
 very soon.
 We have to realize what for next 2 years (and more...), most LO users will
 still use a computer (desktop or laptop) to edit.


Actually, the new version of Nautilus is about as usable on a tablet as the
old version.
The changes have been brought about after careful deliberation -- you can
read about it in-depth at
http://blogs.gnome.org/mccann/2012/08/01/cross-cut/.


 Your modification will be useful for the tablet version of LO, but maybe
 not for the desktop version.


The on-hover button bar is being removed primarily because it causes
frequent accidental errors, not to better suit tablets (although that would
be a good reason as well).


  and it seems to me as a good trend in general.


 This is a personal and subjective opinion.
 UI decisions should be taken based on facts, analysis, polls, statistics.


Actually, I have heard widespread complaints about the on-hover control. I
myself have struggled with it.
Additionally, if you check the control against our design principles [1],
it performs quite poorly. It breaks ux-discovery, since it's not visible by
default, and ux-error-prevention, as any clickable buttons that appear
unexpectedly over another clickable target is bound to result in errors.

Why not allow users to enable/disable such appearing-controls by
 preferences ?
 Everybody should be happy :
 - beginners and average users won't see changes between versions
 - power users may choose what they prefer

 1) It adds complexity (see Hick's law), goes against ux-minimalism
2) It has to be maintained.
3) It adds baggage to LibreOffice, makes it slower, makes the code
less manageable.



 As a general point of view on this subject, I would say that it shows
 several problems in the design team (that's why I'm CCing to design list) :

 - there is a lack of long-term vision for LO's UI/UX : a vision, a
 roadmap, with tenets.


Right now, we're hoping to change LO's UI iteratively, one usability
problem at a time.
Take a look at our design principles [1].

Some big users (administrations, companies...) need that kind of
 information so that they can plan training, migration [1].
 For example :
- should we use or avoid appearing / disappearing UI elements ?


Yes -- they go against ux-discovery and ux-error-prevention.

- should we use floating and/or docked panels ?
When a decision is made, it should not change for several years (3-5)


I disagree.
If a design has problems, it should be changed right away. It's best for
the user.


 - a developer may decide to make big UI changes, just because he talked
 with few users : it's a complete by-pass of the existing UI process
 (whiteboards, proposals, discussions, vote)


That process is for large design changes that need to be thoroughly thought
out.
It would be overkill to spend 3 weeks on minute design changes.

it may also bring some big inconsistencies [2]


It may also bring more consistency, such as in this case, where the
on-hover toolbar was unlike any other toolbar in both LO and elsewhere.


 - most important, it may changes/revert recent modifications -- users
 will be disturbed by those UI flip/flop (for example see previous changes
 between Rythmbox and Banshee in Ubuntu)


That's pure speculation.
I personally expect users to be glad to be rid of a usability nightmare.

[1] http://wiki.documentfoundation.org/Design/Principles
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter

2012-09-26 Thread Mirek M.

Hi Kendy,

On Tue, Sep 25, 2012 at 3:35 PM, Jan Holesovsky ke...@suse.cz wrote:

Hi Mirek,

Mirek M. píše v Út 25. 09. 2012 v 12:19 +0200:

Slide duplication was not easily accessible after this, so I
added it to
the right-click menu:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=980c82bf423bcf89e17b0e45ffc4d946737b8d7b

Could you also show it on the Presentation toolbar?

The Presentation toolbar currently has it, but hidden - when you click
on the arrow next to the Slide (it should be called New Slide, I
guess), it is at the bottom of the control that appears. Do you suggest
to remove it from there, and add a button for that directly on the
toolbar instead?

Yes.
If you feel like it would waste too much space, you could hide Slide
design by default, as it's not very useful in its current state.

And perhaps rename the Presentation toolbar to Slide toolbar, since
all of its commands apply to the current slide, not to the
presentation as a whole.

Makes sense, will do that.

I would also propose to move it to the bottom left so that it sits
directly under the Slide toolbar, where it can be associated with the
current slide (as per ux-natural-mapping [1]).

I meant Slide pane, not Slide toolbar, sorry.

Possible, of course, just it would shift the Drawing toolbar to the
right, and that might hide some items on smaller resolutions. Could you
please double-check if we really want that?

First I asked on our G+ page [1].
Then I took another look at it. Here's my take:
1) We should hide the Gallery and the Fontwork gallery by default, as
they're outdated, promote bad habits, result in bad quality, and are hard
to use.
2) Rotate, Position and Size, Alignment, Arrange, and Interaction
are on the Drawing toolbar, but they have little to do with drawing and
apply to a whole range of objects, not just drawings. I would suggest to
put them in a separate toolbar. I would place it to the right of the
toolbar below the Standard toolbar, as it also contains commands related to
the selected object (ux-natural-mapping).

These changes should improve usability in general as well as make room for
the Slide toolbar below the Slide pane.

[1] https://plus.google.com/102673546895803839652/posts
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Killed the ButtonBar in slide sorter

2012-09-25 Thread Mirek M.

Hi Kendy,

On Tue, Sep 25, 2012 at 10:34 AM, Jan Holesovsky ke...@suse.cz wrote:

 Hi Astron, UX guys,

 I've talked to an Impress power user recently, and he was complaining
 about the buttons in the slide sorter [the thing you can see on the
 attached screenshot].  This was actually not the first complaint I got,
 and also I remembered our discussions that we should do something about
 them, so I decided to just kill them for now:


 http://cgit.freedesktop.org/libreoffice/core/commit/?id=504d3ed897915bff3b3794dc3f069cb4fb528719

 Slide duplication was not easily accessible after this, so I added it to
 the right-click menu:


 http://cgit.freedesktop.org/libreoffice/core/commit/?id=980c82bf423bcf89e17b0e45ffc4d946737b8d7b


Could you also show it on the Presentation toolbar?
And perhaps rename the Presentation toolbar to Slide toolbar, since all
of its commands apply to the current slide, not to the presentation as a
whole.
I would also propose to move it to the bottom left so that it sits directly
under the Slide toolbar, where it can be associated with the current slide
(as per ux-natural-mapping [1]).



 The rest (slide show start, hide slide) are already available easily -
 the former from a toolbar, the latter from right-click menu.  Using that
 feels surprisingly well to me, and visually it is much less disturbing -
 I hope OK for you too?


It's great, thanks.


 This all leads me to thinking that things that appear somewhere with a
 timeout after having placed the mouse pointer there are annoying in
 general [referencing there the header / footer too], so I wonder if we
 have any other occurrences of such behavior around?  I'd probably kill
 it too, in case we do ;-)

 Thank you,
 Kendy

 [1] http://wiki.documentfoundation.org/Design/Principles
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] [libreoffice-design] Language selection menu UX issue

2012-09-19 Thread Mirek M.

Hi Antonio,
I think your query is more appropriate for the ux-advise list, so I'm
CC-ing it.

On Wed, Sep 19, 2012 at 8:23 PM, Antonio Fernández 
antonio.fernan...@aentos.es wrote:

 Hi everyone.

 I am developing the menubar integration with Unity and, during the process,
 I think I have found an UX issue on Language selection menu.

 As language selection menu holds a list of languages to select, I think
 this
 list should be a radio button list (only one option from the list is
 allowed
 to be selected at the same time).

 There are some extra buttons (Reset to Default Language and More...)
 which could be separated from the list using a separator item.

 There is even a inconsistency with other language menu, which in fact is a
 radio button list.

 I am attaching two images to show what I am talking about.

 I was thinking on changing the menu to be displayed more appropriately, but
 I want to know why is it done that way and if there is any problem if I
 change it.

 
 http://nabble.documentfoundation.org/file/n4008258/lo-language-menu-ux-1.png
 

 
 http://nabble.documentfoundation.org/file/n4008258/lo-language-menu-ux-2.png
 



 --
 View this message in context:
 http://nabble.documentfoundation.org/Language-selection-menu-UX-issue-tp4008258.html
 Sent from the Design mailing list archive at Nabble.com.

 --
 Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org
 Problems?
 http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
 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


___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] localize spreadsheet style template names runtime

2012-08-28 Thread Mirek M.

Hi Kendy,

On Tue, Aug 28, 2012 at 11:01 AM, Jan Holesovsky ke...@suse.cz wrote:

 Hi UX guys,

 Any input on this, please? :-)  Should we add it to menu somewhere?

 [Summary: One can apply themes/templates for sheets in Calc, but the
 functionality is buried under a button that is not even visible by
 default.]


Given that there's no way to add or edit the theme and that the default
themes are pretty bad, I would keep it where it is for now.

If we find a willing developer who would at least add editing
functionality, then I'd be open to featuring it more prominently.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] localize spreadsheet style template names runtime

2012-08-28 Thread Mirek M.

Hi Olivier,

On Tue, Aug 28, 2012 at 3:00 PM, Olivier Hallot 
olivier.hal...@documentfoundation.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi

 Em 28-08-2012 08:30, Mirek M. escreveu:
 
 
  Given that there's no way to add or edit the theme and that the default
  themes are pretty bad, I would keep it where it is for now.


 while I agree the themes are pretty tasteless, the point is, 1) if it is
 burried, no one will take care


It's not a good practice to clutter the main UI with useless dialogs, as
per Hick's law.

I also wouldn't say it's an effective way to get developers working on a
dialog. The Gallery, for example, is featured quite prominently, yet it has
gone unmaintained and remains barely useful/usable. And despite styles
being lauded as better than hard formatting and the style dialog being in
the forefront of Writer, Impress, and Calc, the style dialog remains hard
to use, cluttered with a plethora of styles, lacking in previews, and with
style editing hidden under a right-click menu.

2) Why with Impress
 templates/backgrounds and not Calc?


Impress doesn't feature themes and its templates are about as accessible as
Calc's, so this is not really a fair comparison.

If Impress did feature themes, which I hope will happen down the line, they
should be accessible up front if and only if a) they are editable and/or b)
the bundled selection is of high quality, since it's useless offering the
user some bad themes they can't change.

The same goes for Calc.


 
  If we find a willing developer who would at least add editing
  functionality, then I'd be open to featuring it more prominently.

 What exaclty you mean in terms of editing? May be it is just add another
 template at the right place (not checked yet).


Quoting from the Calc Help page [1]: It is not possible to add themes to
Calc, and they cannot be modified.

[1] http://help.libreoffice.org/Calc/Selecting_Themes_for_Sheets
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Change LibreOffice's behavior of how formatting is applied

2012-08-07 Thread Mirek M.

On Mon, Aug 6, 2012 at 1:14 PM, Daniel Mania daniel.ma...@umb.no wrote:

 Hei hei!

 Some time ago I filed a bug report (ID 46517) about LibreOffice's
 subscript/superscript behavior. This report got closed and I would like to
 discuss it here instead and also expand it to formatting in general.

 Currently, if the user activates any formatting (e.g. Text bold), the
 outcome depends on the cursor position:

 a)
 If the cursor is inside a word (behind first character and in front of
 last character), the whole word will be formatted (even though it is
 unmarked).

 b)
 If the cursor is anywhere else, only newly typed characters will be
 formatted.


 This is another example of how LibreOffice forces the user to think about
 the outcome of an action depending on the current situation. And you might
 know by now that I kind of dislike this. ;-)

 Now I would like to know if I am a special case, or if we should change
 the formatting behavior to:

 After a formatting was invoked, only affect newly typed characters at the
 cursor position.
 Of course this only applies if no characters were marked before.


 bfoman stated that the current behavior is the default in MS Word 2010,
 but in MS Word 2007, formatting works like I would expect (and proposed)
 it. An old version of LibreOffice (3.3.4) already shows that behavior and I
 do not know since when it exists. This might be a big change if it is an
 ancient way to handle formatting. On the other side it might be something
 that would not matter to 99.9 % of the users, but changing it would please
 the remaining 0.1 %.


The reasoning behind this behavior is that the user isn't likely to start
typing in the middle of a word, and therefore it makes more sense to format
the word the cursor is in instead of formatting only the letters typed
inside the word. Honestly, I can't think of a use case where the user would
want to type inside a word he typed before, but using different formatting
from the rest of the word.
The current behavior makes it easier to format words -- instead of
painstakingly selecting a word, the user can simply click anywhere inside
that word to apply some formatting.
This may not sound like a huge time-saver, but if one does all his
formatting in one go, perhaps to highlight some keywords, it makes things
much more efficient.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Artwork licensing

2012-07-22 Thread Mirek M.

Hi Michael,
Given that it's unlikely that we'll get an okay from the Gnome icon authors
to relicense their work under the MPL anytime soon, perhaps we could think
about licensing all LibreOffice artwork under the more art-appropriate
cc-by license from now on. This would not only decrease confusion around
licensing in LibreOffice, but would also make it easier for
differently-licensed projects to incorporate our Tango icons and for us to
exchange Tango icons with Gnome.
Would that be a possibility? What is your take on this?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Windows look

2012-06-20 Thread Mirek M.

Hi Kendy,

On Wed, Jun 20, 2012 at 2:14 PM, Jan Holesovsky ke...@suse.cz wrote:

 Hi Klaus-Jürgen, Astron, Mirek,

 On 2012-06-19 at 16:38 +0200, klaus-jürgen weghorn ol wrote:

   I'm still working on making the text (and the closing icon on the
 right)
   black, instead of semi-transparent...
 
  I'm not able to read the first point in the menu: File.
  Maybe this will change in near future by your work but I want to point
  at this fact ;-) .

 This was exactly what I meant by the above paragraph ;-)  So the text is
 sorted out now:

 http://artax.karlin.mff.cuni.cz/~kendy/design-list/toolbar-gradient-3.png

 Please let me know if it works for you; I like it :-) - hopefully you
 too.  I can easily change the size of the glow behind the characters in
 the menu (like, it can be tighter, or wider), and maybe even its color
 (to be 'less white'); and tweak the gradient too, if necessary.


To be honest, I prefer the first screenshot you posted [1], though I still
think a menubar with an opaque background rather than Aero glass would be
best.

Could you at least make the glow behind the menubar items more transparent
and wider?
Also, would it be possible to spread out the menubar items more, such as in
http://upload.wikimedia.org/wikipedia/en/0/0f/PaintDotNet-3.5-Screenshot.png
?
Lastly, compared to MS Office [2], the area of the titlebar and menubar
combined seems to be quite large. Would it be possible to decrease the
height of the menubar a bit?

The only limitation for the gradient is that it currently cannot be over the
 entire 'glass' area, only over the menu area.


 The closing button is the remaining issue now, I believe.

 All the best,
 Kendy


[1]
http://artax.karlin.mff.cuni.cz/~kendy/design-list/toolbar-gradient-2.png
[2] http://www.james-greenwood.com/wp-content/uploads/2009/08/word2010-1.png
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Mirek's visit in SUSE :-)

2012-05-25 Thread Mirek M.

2012/5/25 Jan Holesovsky ke...@suse.cz

Hi Astron,

Stefan Knorr (Astron) píše v Čt 24. 05. 2012 v 13:23 +0200:

Kill INSRT/OVER (and introduce 'Overwrite' only when overwriting):

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b30e202861e9bdba4d86e76ba8a6f059da8efc31

Here, I would like to propose two things:
* make Insert mode harder to trigger, for instance, by having to use
Shift+Ins (instead of just Ins)
* remove the inidactor wholesale

That is actually an interesting idea :-) The cursor changes to a block
one when the overwrite mode is activated, so together with making it
harder to trigger, it might be OK.

Anybody against this?

I would prefer if the shortcut was kept as Insert, as that's the shortcut
used by virtually every other application that allows overwrite mode.
Also, could the cursor stay a block even at the end of the line, so that
the user knows he's in overwrite mode?
Alternatively, I've seen some applications use a red cursor instead of a
block, which would be more effective at communicating to the user that he's
in overwrite mode.
See https://docs.google.com/open?id=0B_RBf0YVtxzkZFZTMU5YUmR4S1U for what
it might look like.

There are few more things still to be done, the most important ones
that
we talked are:

- more helpful STD/BLK/... etc. selection statusbar indicator

Do we really need indicators for the selection modes at all? They are
sufficiently hard to trigger and a sufficiently minor use case to
ignore them in the main window, I think.

Too late, I've implemented that in the meantime :-)

http://artax.karlin.mff.cuni.cz/~kendy/design-list/selection-mode-status-bar.png

Great!
The names for the selection modes don't correspond with those on the help
page (http://help.libreoffice.org/Common/Selection_Mode), though -- could
you edit one of them so that they're consistent?

Also, the icon looks a bit off-center -- do you think you could center it
between the two separators? Lastly, would it be possible to show the menu
above the status bar, with its left border aligned with the separator to
the left of the selection mode icon?
I know I'm being nitpicky here...

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f76fde91c4103812d924b973cec83a7b316a1f05

I think it might be unused these days because nobody knew what the three
letter acronyms actually stood for; but maybe I am wrong.

Either way, it is at least usable and better looking now.

- improved Windows 7 look (nicer menus + toolbars there, make use of
the
drawing into the non-client area)

I took a look at it... nice, but currently also unusable, because the
text can't be read.

If you mean what is in master now, that is only a proof-of-concept of
drawing into the non-client area, unfinished work. But I'd like it to
be a bit different, I'll start a thread on the design@ list about that.

Regards,
Kendy

___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Typography

2012-05-24 Thread Mirek M.

Not having received any response to my initial e-mail, perhaps because of
its length, I'll post some simple questions instead:
Will we be able to ship with some open-source fonts other than Liberation
fonts? How many?
We will need some fonts for our new templates...
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] A sheet by default

2012-05-21 Thread Mirek M.

Could we vote on this issue, then?
I see that both Google Drive's Spreadsheet application and Excel:Mac 2011
(on my mother's computer) use one sheet by default, so it seems like 3 are
really not needed.
The existence of the sheet bar, the plus button on it, and the label Sheet
1 (the 1 indicating there can be more) should be enough to indicate that
the user can create more sheets.
One sheet also means less confusion for users, as most now ignore the two
other sheets and don't even bother to check if they have content.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Fwd: Ubuntu Templates

2012-05-20 Thread Mirek M.

Hi Bjoern,

2012/5/20 Bjoern Michaelsen bjoern.michael...@canonical.com

 Hi all,

 On Sun, Apr 01, 2012 at 03:44:09PM +0200, Alexander Wilms wrote:
  here's the Wiki page:
 https://wiki.documentfoundation.org/Ubuntu_Templates

 I assume the development has moved elsewhere in the meantime?


Kind of. There's a call for CC0/public domain templates going on right now
at https://wiki.documentfoundation.org/Design/Call_for_Templates . The CC0
license has been chosen to allow for any use of the templates (without the
presenter having to mention the author's name or being restricted by
copyleft or into using the templates with only our software).


 Anyway, upstream feature freeze for 3.6 is closing (2012-06-04) in:

  http://wiki.documentfoundation.org/ReleasePlan#3.6_release

 so I would like to have integrated whatever we have right now and replace
 the
 old default masterpages with them, because frankly: they are _really_
 ugly. I
 am talking about these:

  http://opengrok.libreoffice.org/xref/core/extras/source/templates/layout/

 I agree.


 @Alexander Wilms: The typography templates at
 http://templates.libreoffice.org/template-center/typography look
 beautiful and
 I would like to make them a replacement for the biggest and most ugly of
 the
 current templates, which are:

 1.1M May 19 21:57 extras/source/templates/layout/lyt-book.otp
 706K May 19 21:57 extras/source/templates/layout/lyt-forest.otp
 690K May 19 21:57 extras/source/templates/layout/lyt-paper.otp
 639K May 19 21:57 extras/source/templates/layout/lyt-glacier.otp
 638K May 19 21:57 extras/source/templates/layout/lyt-wine.otp

 which in all their ugliness do not justify the space they eat in the
 default
 install. Any objections to that?


 Do we have any more masterpages we could use to replace the ones above? As
 frankly, the current ones are _really_ ugly -- so even if want you have is
 not
 perfect, it is likely better than what we would ship with now (after
 replacing
 the above 5 templates there would still be 25 of the old ones left).


Take a look at the wiki page mentioned above:
https://wiki.documentfoundation.org/Design/Call_for_Templates#Submissions
These should all be licensed under CC0.


 The vintage, fresh and serious, Rounded Rectagles and Hexagons
 templates do not look too bad too me. Does anybody know the authors and can
 ping them if it is ok to directly include their work under MPL/LGPLv3+?


I believe most of that (except Rounded Rectangles) is Alex's work, too.


 Best,

 Bjoern

 P.S.: At UDS we talked about moving our templates to an universe package.
 Back then I was talking about these templates:


 http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=tree;f=ubuntu;h=4d6fb808aed6d29944bc4980aae9ce3401e85ec1;hb=refs/heads/ubuntu-oneiric-3.4

 however, given how ugly and big these upstream masterpages are:

 506K May 19 21:57 extras/source/templates/layout/lyt-keyboard.otp
 496K May 19 21:57 extras/source/templates/layout/lyt-water.otp
 491K May 19 21:57 extras/source/templates/layout/lyt-rededges.otp
 321K May 19 21:57 extras/source/templates/layout/lyt-numdark.otp
 306K May 19 21:57 extras/source/templates/layout/lyt-techpoly.otp
 286K May 19 21:57 extras/source/templates/layout/lyt-bluegrey.otp

 we could replace those 6 upstream with the ones from Ubuntu (excluding the
 explicitly Ubuntu-branded one), which are not exactly beautiful, but better
 that the defaults upstream. With that we would have 11 new masterpages
 upstream
 (leaving us with 25-11=14 old ones we would still need to replace).
 Opinions?


I'm all for it, though we would need to convince the authors to release
these under CC0.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Full customization of LibreOffice

2012-05-06 Thread Mirek M.

2012/5/6 Daniel Mania daniel.ma...@umb.no

 OK, once again I underestimated the effort needed ...
 I would be happy to start a whiteboard together with someone who actually
 has some programming skills, if the list agrees.


The problem is finding an interested developer...
Any interested developer on this list, by any chance?


 DM
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Java GUI for Libre-Office Based Android App(s)

2012-04-28 Thread Mirek M.

Hi Tor,
I'd like to make some whiteboards to work on this so that the design team
can get started on designing.
I believe the file manager whiteboard [1] could suffice to design the file
management part of the UI.
As for the file viewer part, I've made a separate whiteboard for that [2].
Could you tell me what features should and should not be present in the
designs? (This lets me define the scope.)
Some specific things I'd like to know:
- Should we design for Draw or not?
- Will you support note viewing? What about advanced navigation (think
Navigator)?
- Should the design count on the viewer evolving into an editor?
- Should there really be no editing features? Not even basic text editing
without formatting commands?
- Should we design for both tablets and smartphones?
- How long do we have to design this? 3 weeks?

Thanks. :)

[1] https://wiki.documentfoundation.org/Design/Whiteboards/File_Manager
[2] https://wiki.documentfoundation.org/Design/Whiteboards/File_Viewer
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Java GUI for Libre-Office Based Android App(s)

2012-04-26 Thread Mirek M.

2012/4/26 Tor Lillqvist t...@iki.fi

  Which three aspects? Writer, Impress, and Calc or Writer, Impress, and
 Draw?

 Writer, Impress and Calc. I doubt LO's vector-drawing functionality is
 that relevant in the tablet marketspace, surely there are much better
 apps for that?


Draw could be a great vector editor if it made color management better (we
have a whiteboard for that, too, by the way [1]).

That said, I always saw Draw more as a desktop publishing application, as
its UI centers around pages, which have little to do in a vector drawing
program.

In any case, I hope you reconsider making a Draw port for tablets. I heard
Draw shares a lot of code with Impress, and UI-wise, it's very similar to
impress as well, so I'm guessing that porting it might not be that painful.


 (That said, I don't actually know if that is true;
 after all vector drawing is a niche, bitmap-based drawing is what the
 public in general understands...)


You're right -- the general public hasn't warmed up to vector editing yet.
I believe the best image editor would merge the features of bitmap and
vector editors, in a way similar to Macromedia/Adobe Fireworks.

I don't think there's a good vector editor out there for tablets, certainly
not an open-source one. There seem to be more tablet office suites than
vector editors.


 Base, well, it is rather un-loved even on desktops. Of course, this is
 just my opinion/impression...


I agree.

[1] https://wiki.documentfoundation.org/Design/Whiteboards/Color_Handling
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Colors in ODF

2012-04-07 Thread Mirek M.

I'd just like to ask: How are colors managed in ODF?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

93 matches

Mail list logo