Re: I know I shouldn't but I'll do it anyway....
Hi everyone, linking back to ancient times (dont be confused by the branding :-) http://wiki.openoffice.org/wiki/User:ChristophNoack/Drafts/WelcomeCenter_2010 Cheers, Christoph Noel Grandin noelgran...@gmail.com schrieb: On Fri, Feb 15, 2013 at 7:57 PM, Olivier Hallot olivier.hal...@documentfoundation.org wrote: suggest to replace the start center with a grid of recent files thumbnails... Whoever opened an Office 2013 application with no document loaded knows what I am talking about. And we can do better. Good idea. I don't see why we can't have both links to the applications and a set of recent files. I have no idea why start screens always use so little of the available display. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Sent via mobile...___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [libreoffice-design] Re: [Writer] Header/footer deletion from the UI
Hi everyone! Am Sonntag, den 28.10.2012, 02:34 -0600 schrieb Adolfo Jayme Barrientos: I agree, the deletion alert is unnecessary. If the user wants to recover the header, they should be able to do so by using the “Undo” functionality. Yes, but it has been kept, because a major problem hasn't been solved since years ... please see: http://wiki.documentfoundation.org/Design/Whiteboard/Writer_SpecialIndicators#Known_Issues If anybody could adress this issue first, that would be great! Kind regards, Christoph On Sun, Oct 28, 2012 at 2:18 AM, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net wrote: Hello, (not sure whether this goes to design or ux, so I'm flooding both :) LibO version 3.6.4.0+ (Build ID: 2f42a6c) Xubuntu 12.04 Writer interface - Using the header (resp. footer) option in the UI 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). Thanks for your comments, -- Jean-Francois Nifenecker, Bordeaux ___ 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
[slightly OT] Re: rediscovered: missing writer documentation
Hi Thorsten, all! Am Donnerstag, den 05.07.2012, 19:42 +0200 schrieb Thorsten Behrens: Italo Vignoli wrote: I have an idea to leverage the document for a LibreOffice Story which connects 1998 to 2012, and introduces LibreOffice 3.6. It would be nice to find some other LO paraphernalia, from the early conferences. I have something in my archive, but others might have additional stuff. Have some SO 4.0/5.1/5.2/6.0 and the odd StarMedia cliparts collection CDs around + boxes - can mail you pictures. :) If one needs additional pictures, I still have some older pre-StarOffice software boxes from DOS times: http://uxopenofficeorg.blogspot.de/2010/09/stuff-on-shelf.html Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] Header/Footer widget ...
Hi Michael, hi all! Am Montag, den 28.05.2012, 13:51 +0100 schrieb Michael Meeks: Hi there, I was accosted at LinuxTag by a chap who had clicked in his footer area and had a footer inserted without wanting that, and of course deleting it throws your cursor to the top of the document loosing your place ;-) Thanks for sending this feedback! Well, re-placing the cursor is far better in comparison with the deleted undo stack when inserting the header / footer ... :-\ It seems he's right; the control there is sensitive from the time it begins this fade-in, so if you click in the right place you get this behaviour. I suspect we should: a) make that button insensitive until it is fully faded in visible for say 500ms (we can bikeshed the number) Well, I propose a different approach - everything that's visible and that looks like a control should be active. So my proposal is to present it a bit earlier (but unobtrusively) and to make it fully visible when the mouse pointer hits it. Details: * The behavior for showing the control is dependent whether the mouse pointer is placed on the control or not * If the mouse pointer just hovers the header / footer area for a certain amount of time (500 ... 1000 ms), then the control is faded in a bit (intermediate state, showing it 50% visibility or something like that, fade-in time approx. 250 ms ... 500 ms) * If the mouse pointer starts to hover the control ... * and the intermediate state (50% transparency) hasn't been reached yet, then jump to at least 50% visibility to show the control reasonably well. Then ... * it is faded in completely (approx. 125 ms fade time) (working state, 100% visibility) * If the mouse pointer hovers the header / footer area for a longer time (10 s ???) without using / hovering the header / footer control, then fade out the control (250 ms) and keep it inactive until the user re-enters the header / footer area with the mouse. I've started a similar description some time ago, but the current behavior seemed sufficient ... in the motivation I've mentioned full fade in / out avoids being surprised when the markup appears (refers to full fade in when hovering the control): http://wiki.documentfoundation.org/Design/Whiteboard/Writer_SpecialIndicators#Definition_.22Interactive_Header_Footer_Indication As you said, bikeshedding (iterating to get further improvements) needs to be done ... By the way, the behavior is rather similar to what would be helpful for the Insert New Comment control in the Comments Side Pane I'm still hoping for ;-) b) move the cursor back into the page, either top or bottom that is currently visible when it is deleted through the UI Sounds good! Thoughts appreciated of course :-) not sure if you have any cycles for this sort of thing just now though. Cheers, Christoph ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
License Statement
Hi all, just to be sure ... All of my past future contributions to LibreOffice may be licensed under the MPL/LGPLv3+ dual license. Cheers, Christoph Noack ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] Bug 44216: Drag and Drop Slides distorts object's height/width ratio
Hi all! Am Montag, den 20.02.2012, 19:07 +0400 schrieb Ivan Timofeev: Hi Astron, On 17.02.2012 21:41, Stefan Knorr (Astron) wrote: [...] I have taken a look at the existing message (it only appears when Ctrl-C'ing the slide and then Ctrl-V'ing it) and I find it not ideal. (It asks for Yes/No/Cancel, which is a labour-saving but user-confusing artefact of Win GUIs.) I'll try to think of something, maybe... Hmm, is there any possible alternative? This is - like in many other cases - a candidate for for the following scenario: * The user does something which implies LibreOffice to respond in several (almost equal) ways * We don't know what alternative the user might prefer for his special use case The message box asks the user before LibreOffice acts, but it might interrupt the user's workflow. So another alternative is to do something (hoping that we got it right) and to enable the user to decide afterwards. Microsoft Office does this via Action Refinements. Some years ago, I've derived a similar solution incorporating some more use cases: http://wiki.services.openoffice.org/wiki/User_Experience/DirectManipulationSnippets Of course, nothing that gets implemented just for this bug, but I keep noticing that this behavior would be handy in (literally) hundreds of cases. Cheers, Christoph PS: Feels good to be back on the list again :-) ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Headers / footers / page break indicators read-only documents
Hi all, I totally share the view by Michael and Astron to avoid showing these markers in read-only mode. Although LibO's behavior is not optimized for just consuming content but editing it, the missing indicators are also some clue that the document cannot be edited. Thanks for asking for thoughts on ux-discuss... :-) Cheers, Christoph -- Sent via mobile... Michael Meeks michael.me...@suse.com schrieb: On Wed, 2012-02-01 at 08:41 +0100, Stefan Knorr (Astron) wrote: My opinion is that in read-only mode, LibO should feel as much as a PDF reader as possible to avoid annoying the user while e.g. proof-reading his own document or just reading someone else's document. I hate plus-ones; but this is mine :-) It's a cool new feature, but we should avoid getting too seduced by the joys of showing it everywhere ;-) All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot _ 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] [Libreoffice] [PATCH 3.5 and master] Avoid UI bugs in translations
Hi all! Adding Josh, since he provided the initial patch to improve the dialog. Furthermore, there is a recent bug reporting this issue (also) for the German translation. So, whoever has the power of the source *g*, please subscribe (assign) to it: https://bugs.freedesktop.org/show_bug.cgi?id=44155 Am Samstag, den 07.01.2012, 11:54 +0100 schrieb Stefan Knorr (Astron): Hi all, So... 1. The change of the title (Text to Text [en-US]) seems extremely sensible to me and should get in as early as possible, so other translators see the new string too. Good catch! Especially, since I missed that we now use a different string than $PRODUCTNAME. However, the currently used Save is a bit misleading to me, since (at least in Gnome) it is also used in the preceding Save As dialog. Our recent dialog is about asking the user whether he is sure about the chosen file format. If we decide to use the title bar text, could we please use something like: Confirm file format / Use of file format. Astron, your thoughts? For the record, Gnome suggests to avoid title text for alert windows: http://developer.gnome.org/hig-book/3.0/windows-alert.html 2. The question you added seems sensible to me, even though it makes the text even longer [1], so should probably get in. Also, it would be great, if you could remove or at least comment out the en-US-old thing, that seems mighty confusing. 3. It is a bit of a problem to use button labels without a verb (or alternatively OK) and also probably goes against most HIGs, so not a good idea IMO. William, is it a possibility to use just Utiliser ODF just for French (that this is a file format is made clear before, anyway)? Mmh, although I understand the rationale, I fear that the recent changes make the dialog more complicated that it was before Josh initially touched it. The body text is now longer (having the real question at the end), whilst the buttons don't reveal to less advanced users what they are for. People usually scan the button text first, before they start reading the alert text. So my suggestion is to keep the current behavior. William, does Astron's proposal sound reasonable? That would be great ... Astron mentioned the missing consensus - maybe we can further improve for the next release? I still think that something like [Confirm WhatEver Format] [Switch to ODF] or [Use WhatEver Format] [Use ODF Format] would be more helpful. The rationale can be found here: http://lists.freedesktop.org/archives/libreoffice-ux-advise/2011-August/000209.html 4. I have a few reservations against using Statistics instead of Word Count. While, technically, you're right, the word count is just part of what you get, Word Count seems much more digestible to me and is also the main use of the feature. Also, it used to be called Word Count in all older English version, too. +1 to use Word Count for the same reasons. However, thanks for fixing the en-US tag. For the record: some statistics (German equivalent: document statistics) are already available in File - Properties - Statistics. [...] Cheers, Christoph ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] [REVIEW 3-5: Late feature] Improvements in the header / footer behavior
Hi Astron, Kendy, Cedric and Cor! Kendy, I've noticed your mail since I try to follow the mail stuff from time to time ... still not real chance to be a bit more active. Hope to change that soon. However, I'm now sitting on my tethered laptop with a painfully slow network connection :-) Am Donnerstag, den 29.12.2011, 17:42 +0100 schrieb Stefan Knorr (Astron): Hi Jan, Cor, Cédric, both of the things you fixed were conscious decisions, but after seeing how well libo works with your patches, I think, they weren't good decisions after all, so +2 for your patches. Concerning ... * Change #1: Faster fade-in I don't fully understand the change, whether it is a faster fade-in or whether the control appear without delay. If the latter, I fear that people will be heavily bothered if they just move the mouse cursor or park their mouse pointer anywhere. Personally, I think that reducing the delay to 500ms (from 1s) is reasonable. It would be cool if you could have a look at the recommendation about how to make it behave better (could not be implemented in the given time, I assume): http://wiki.documentfoundation.org/Design/Whiteboard/Writer_SpecialIndicators#Behavior_2 So the idea was to have some more intelligent handling to balance the show as early as possible vs. don't bother the user. I'm sure some details are still missing (e.g. I thought about removing the markers after some time of mouse inactivity). Once we have a good working behavior, I recommend using it for all the (upcoming?) visual markers we have in LibO. * Change #2: Separate handling of header/footer I haven't tried that yet (download too slow), so I can just state the reasons. Maybe it helps to decide ... * Word handles the header/footer area the same way, so we show these special ranges at the same time. * It also directly shows the user the current status of the other area (e.g. if a footer is enabled, not just empty). * I saves some time for the user for the controls to appear; and it makes things less visually noisy. By the way... It is because there is no real animation framework used / existing, the controls are just painted several times with various opacity, which is not ideal, but best we can do for 3.5 I am afraid. Is there any way, we could use Impress's animations for this in the future? Hhm, clueless guess ... wasn't the Drawing Layer made for that? The Sun guys told me years ago that smooth animations would be possible. Something I still really miss for the Notes in the side pane - less jumping ;-) However, since we soon start into 2012 - I hope you all are well, you have been able to enjoy family and friends, and you'll have an amazing new year. Cheers, Christoph ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice] [Patch] Remove OOoImprovement
Hi all, I'm not fully sure whether you refer to the OpenOffice.org improvement program. If yes, then this issue had been discussed some months ago. I also had some discussions with others (e.g. with Michael at the LibOConf) how to get that back working. Here is one of the mails: http://lists.freedesktop.org/archives/libreoffice/2011-January/006178.html Cheers, Christoph PS: I'm currently 99,9% offline due to personal stuff, so (if anybody cares) sorry for not replying (also) on the other lists :-\ Am Freitag, den 16.12.2011, 00:20 -0500 schrieb August Sodora: Hello, I realized there were still a few things left over from the testtool removal so I created the attached patch. There seem to be some logging-related things left in comphelper and officecfg that are used all over the place but I'm not 100% sure about them yet. Would somebody mind reviewing/pushing this? I was forced to upgrade and am still waiting for my gpg key to be changed. August Sodora aug...@gmail.com (201) 280-8138 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] Manage Names Dialog hit master
Hi Markus, Astron, all! @ Astron: Thanks for your incredible help during my time being offline :-) Am Montag, den 05.12.2011, 21:37 +0100 schrieb Markus Mohrhard: [...] Then we still need an information string for the case that the formula is not valid. At the moment I don't display anything in this case. So here a small question - are there different cases for a formula being invalid? Like having the wrong characters, or referring to reserved names, ... and what not. The most simple case would be: Invalid range.. [...] We now highlight the info text if we have an error in the name or in the formula. I was unable to change the background color of the range edit line or the name edit line. Mmh, if I could only remember where I had seen such behavior ... I'm sure there is such a dialog having the colored background on error cases. However, what I've noticed is that the error message (Invalid name) is shown although there is no name entered. If the name is not entered yet (text field is empty), then please show the default message. That might sound friendlier to users :-) Some visual fine tuning: * please place the center in the mid of the rectangle (still left-aligned) * the background color for errors should be yellow instead of blue (has rather neutral meaning) And a question: Is it intended that we jump to the range entry once we open the dialog? To me it makes most sense if we start with the topmost entry (assuming that the #1 use case is: people pre-select the range and then open the Define Names ... dialog to provide the name). Then again a big thanks to you guys, you made this amazing work possible. I already added a comment to the 3.5 release notes and it would be great if someone of you could add a screenshot. Indeed, thanks to you all (especially you Markus, and of course Stefan) ... a very joyful experience :-) I skip adding the screenshot, since only a few minutes are left and I think I've found a crasher related to the header / footer indicators. Will investigate there ... Cheers, Christoph ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Modify the format paintbrush behaviour
Hi Maxime, all! Wow, you ask somebody who never was in favor of having so many different transfer the formatting-functionality in LibreOffice / OOo ;-) Am Donnerstag, den 24.11.2011, 14:59 +0100 schrieb Maxime de Roucy: Hello I am the author of https://bugs.freedesktop.org/show_bug.cgi?id=43067 For me the format paintbrush function should copy and paste the exact format of text and paragraph. The selected text where the format is apply should look exactly like the text where the format has been copied. Do you agree ? So, I've read parts of the spec, looked at the LibO issue and the OOo issue. So if I get it right, you ask whether the hard formatting from the source object should replace any hard formatting of the target object? Today, we seem only to add the hard formatting to the target. Right? If yes, then I agree with your point-of-view - although we do have lots of user who might be used to the given kind of behavior. And now my *personal* point-of-view: There shouldn't be a format paintbrush, but the copy-and-paste functionality might be used as well to copy styles / formatting. Cheers, Christoph ___ 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 range name dialog proposal
Hi all, A quick mobile answer: I'd like to avoid any unwanted jumping from within the dialog, so if we can avoid any jump in the document when the dialog is opened, that would be good. But, at the same time, I'd suggest to have the focus in the table when opening the dialog, so the user can start navigating. To me, two contradicting goals at the moment. But maybe not setting the focus in the table, but on e.g. the add button helps. More thoughts later ... maybe not today. Enjoy your day, Christoph -- Sent via mobile... Astron heinzless...@googlemail.com schrieb: Hi everyone, After implementing parts of the Select Range button I think it is redundant. If you want to see the range then you can either go to the range line directly or click the button after the range line and the range is highlighted in the document. I think that for nearly all use cases this should be enough. Ah, so changing the range expression also jumps towards the target. Yes, then it is less needed. But let's have a look at the default functionality in the dialog (pressing ENTER, or double clicking on an entry). Having no Select Range leads to the alternatives ... * Going to the Text Field Name makes sense visually - it is the very next field. But I assume that name changes are less likely than checking / modifying the range. Thus, undesired. * Going to the Text Field Range might make sense from the use-case point-of-view. But, we don't have a default functionality visualization like for buttons. Thus, people won't know that easily. Furthermore, using the keyboard and jumping to the ranges (the visual check) doesn't work anymore, since the focus is moved from the table to the edit field. * Avoid to go to any input field / button, but executing select range (without having such a button). But, user don't see this functionality and I don't know whether omitting this button will cause problems for accessibility. If I may voice an opinion, I happen to agree with Markus on this issue – I think the visualisation should appear on single-clicking/↓↑ arrow selecting the list entry, as it does today and of course when modifying such an entry. For a solution to the focus problem, why not go for option 1? * Name is the most inconsequential field (given that the names are updated automatically in formulas when applying), so if the user doesn't notice the focus change immediately after double-clicking, it won't hurt at all. * Going to range is just one extra tab away. * It makes sense for keyboard users. (Entry table, Tab→, Name field, Tab→, Range field, Tab→, Scope field, Tab→, Range Options, Tab→ (the five buttons), Tab→, Entry table) * It makes sense visually. I hope that beginning of next week the first big part of my work hits master. It is only a rough plan and I'll drop you a second note as soon as I pushed all my changes and think it is ready for some first tests by you. Will love to try, too. Astron. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice] [Libreoffice-ux-advise] [PATCH] Start Impress without the wizard by default
Hi Michael, Tim, all! @ Michael: As always, thanks for forwarding. @ Tim: Thanks for the patch! :-) Am Freitag, den 18.11.2011, 15:54 + schrieb Michael Meeks: On Fri, 2011-11-18 at 16:37 +0100, Cor Nouws wrote: We do have Tools Options Impress General ... New document .. start with Wizard to turn of the wizard all together. That should do it ..? Right, just changing that default would be easier. Tim - the best way (or at least what I'd do) to find that is to cp -a your ~/.config/libreoffice to somewhere else; change the setting, exit, then diff -ur on the files, perhaps xmlint --format them, and diff -u again - then hack the default setting in officecfg. Any chance you can tweak your patch to that ? If one wants to go a bit further, I'd suggest to (if possible) move the wizard to the Templates and Documents handling. Basically, the core of the wizard seems to be to select proper master pages and to generate a basic structure. That would mean: * Application Menu File -- Wizard: Remove the entry Presentation... - Rationale: It is a mixture of different kinds of wizards. And, only few people seem to use them (from my experience on former user lists). * Dialog Templates and Documents -- Rationale: As said, it lets the user select master pages and structure. At the moment, its unclear to me how this dialog works and whether the presentation dialog can easily be added. * Presentation Wizard: Remove page 1 (so skip the blank presentation, the open presentation thing) -- Rationale: Remove clutter, especially since most of the stuff is already done by the Start Center / other menus. * Option: Maybe, remove the option Cor mentioned. But maybe wait one release to wait for some enlightening feedback by our users ;-))) From my point of view, it could help to reduce the clutter. Cor - you didn't tell us if you thought this was a good default; so far Astron agrees, and Tim of course ;-) +1 ... good thing :-) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] [PATCH] Word count dialog modeless
Hi Matt, Kevin, Michael, Astron ... all! First and foremost, Matt, thank you for the extremely helpful patch ... or (speaking as a non-developer), for the great improvement. Awesome! I finally had some time to test it and I'd like to point out three (mostly tiny) things... First, since the dialog is now non-modal, the OK button does not have the desired meaning anymore. Close is more appropriate in this case - could you please update that? Second, the menu item Word Count is now a toggle for the dialog - that's fine. But in this case we need a checkbox in front of the menu item (true = dialog is enabled, false = dialog is not disabled). Next, I played a bit and run into an issue when working with the Writer Comments. Steps to reproduce: 1. Prepare a document with text, and comments - set the cursor into the text 2. Open the word count dialog - the word count is correctly displayed 3. Click into any note - the word count dialog disappears 4. Press ESC to exit the note Expected result: The word count dialog appears and shows the correct values. The cursor is back in the document (to continue typing). (Mmh, is it possible to show the dialog also when editing the comments?) Current result: The word count dialog appears, but shows no numbers. The cursor is not in the document. (To me, it seems the Word Count dialog gets the focus instead of the document). Can you reproduce that? Shall I create an issue for that? Matt, I hope you find that information somehow helpful. It would be cool if some things could be implemented ... thank you again! Cheers, Christoph Am Mittwoch, den 16.11.2011, 13:44 -0500 schrieb Kevin Hunter: At 12:51pm -0500 Wed, 16 Nov 2011, Astron wrote: On 15 November 2011 19:15, Michael Meeks wrote: :-) sounds reasonable. My only concern would be to make it discoverable and of course performance: would we take a per-keystroke hit there ? so perhaps having it easy-to-enable but disabled by default would make sense. How large is the hit? Has anyone measured already? Personally, I can't really perceive anything when comparing writing with the Word Count window open v/ without it. It seems to me to be an issue of how one implements the word count statistics collection. Are the word count statistics constantly kept up-to-date via a incrementers/decrementers per key-stroke? Or are they only collected upon request? From a brief and unscientific test of copying 10MiB of copy and paste text into a Writer document, waiting while it paginates to 2250 pages, then timing how long it takes for the Word Count dialog to give results, it would appear the former: every keystroke /already/ calculates the these statistics. Thus, my first un-educated guess is that this should have very little performance impact. Cheers, Kevin ___ Libreoffice-ux-advise mailing list libreoffice-ux-adv...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] [PATCH] Make the toolbars not popping-up randomly
Hi Cor, hi all! Am Freitag, den 18.11.2011, 23:08 +0100 schrieb Cor Nouws: Christoph Noack wrote (18-11-11 22:01) Well, I think I don't get everything from the technical description, With the patch, initially the pop-up-behaving toolbars are docked above the status bar. Thanks for the explanation! so I really have to try. Well, since I wanted to try out other features as well, I've installed a recent daily build and here are some comments. Before I start, I really have to say that the concept derived from OOo has its disadvantages (whether the toolbars are floating ones or docked). According to my tryout: * If toolbars appear at the bottom, they might not be noticed easily recognized (not within the primary area of focus). Especially since there is a connection click on the object - toolbar appears which enables learning for the user. * Toolbars are horizontally stacked. Thus, on my VM system (medium resolution display) working in a table (toolbar #1) with bullets (toolbar #2) is hard. Only two buttons from toolbar #2 are available. Thus, I fear that some people might not even notice its existance. (There may be other examples.) * If users have rather large screens, then the mouse travel distance is increased. * When we've presented some proposals within the OOo Renaissance project, people mentioned that vertical space is valuable due to widescreen displays. Consequently: Whilst I'm thinking that its better for users who know OOo / LibO well, it may make things tough for new users. Unfortunately, I have no better solution at the moment - without changing the concept that much. But maybe the points I've raised help to judge the impact ... maybe there are also other ideas around. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [Libreoffice] [PATCH] Make the toolbars not popping-up randomly
Hi Cor, hi all! Am Freitag, den 18.11.2011, 23:08 +0100 schrieb Cor Nouws: Christoph Noack wrote (18-11-11 22:01) Well, I think I don't get everything from the technical description, With the patch, initially the pop-up-behaving toolbars are docked above the status bar. Thanks for the explanation! so I really have to try. Well, since I wanted to try out other features as well, I've installed a recent daily build and here are some comments. Before I start, I really have to say that the concept derived from OOo has its disadvantages (whether the toolbars are floating ones or docked). According to my tryout: * If toolbars appear at the bottom, they might not be noticed easily recognized (not within the primary area of focus). Especially since there is a connection click on the object - toolbar appears which enables learning for the user. * Toolbars are horizontally stacked. Thus, on my VM system (medium resolution display) working in a table (toolbar #1) with bullets (toolbar #2) is hard. Only two buttons from toolbar #2 are available. Thus, I fear that some people might not even notice its existance. (There may be other examples.) * If users have rather large screens, then the mouse travel distance is increased. * When we've presented some proposals within the OOo Renaissance project, people mentioned that vertical space is valuable due to widescreen displays. Consequently: Whilst I'm thinking that its better for users who know OOo / LibO well, it may make things tough for new users. Unfortunately, I have no better solution at the moment - without changing the concept that much. But maybe the points I've raised help to judge the impact ... maybe there are also other ideas around. Cheers, Christoph ___ 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 range name dialog proposal
Hi Astron, Markus, all! I feel like a lame duck at the moment, just too much to do in my day job ... thank you both so much for you patience. So, I'll try to answer you questions / remarks on the last proposal I've made. Am Montag, den 07.11.2011, 14:59 +0100 schrieb Astron: Hi Christoph, everyone else, Astron: Could you please have a look as well? Thanks!!! The mock-up looks good, mostly. Except for going for a wider Manage Names... dialogue I woludn't have done it much different. The few things I still question are: * Add should really be paired with Remove, not with Delete. Ah, yes, you already wrote that some time ago ... I don't know why I missed to update the mockup. Done. * If we have a separate dialogue for Paste again, do we need the Select range button? I hope my description is okay, because these two functions are independent to me. The Select Range button simply selects the cell range like the Navigator or the Name Box would have done. If people manage the names, I simply assumed they will need that functionality because it really helps to do (visually) quick checks of the entries. * Do we (now that it's all modal) really need a separate Define Names dialogue? I think it is still helpful to have such a dialog. For two reasons: * it is much smaller than the Manage Names dialog, so it needs less screen space when defining a name (e.g. for people who don't like / know the name box) * it just needs 2 clicks calling the dialog - for the Manage Names dialog it would be 3 clicks and some more mouse movement It is still miles better than the old dialogue, so go for it. Thanks ... and as Markus said, I'm happy to help with further refinements after our first good solution. Thanks a lot for your input Astron, it is just fantastic to have you around! Cheers, Christoph ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice] [PATCH] for 3-4: remove/change help links to *.services.openoffice.org
Hi Andras! Thanks for taking care ... I'd like to ask a question concerning the patch (and you might quickly notice that I'm a non-hacker). Am Dienstag, den 25.10.2011, 14:48 +0200 schrieb Andras Timar: Hi, *.services.openoffice.org will move to Apache infrastructure soon. The attached patch redirects links to TDF infrastructure. After push, there I'll push the follow-up patch to translations module. I'll create the missing pages in TDF wiki ASAP. This was a quick hack, for 3.5 I would like to check every link whether we really need it. When looking at the patch, I see e.g. the change from: http://wiki.services.openoffice.org/wiki/MSA-Base_Faq to: http://wiki.documentfoundation.org/MSA-Base_Faq Does this mean that we'll convert the given structure of the OOoWiki to the TDF wiki? If yes, do you think its helpful to ease the maintenance of such pages to either use subdirectories (like some of the links already have /Documentation/How_Tos/) or to redirect to the real LibO online help (don't know if pages can already be edited)? Consequently, might this be something for the documentation team? Thanks in advance! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] new range name dialog proposal
Hi Astron, thanks for the input ... most of your remarks can be explained and I'll do that this evening. At the hackfest and the conference, Markus was so kind to explain a lot of constraints we have here. Nevertheless, if you have a mockup, I'n happy to see fresh input (please have a look at. The wiki page first, some design goals are explained there). Now, I am approaching my day job ... Have a nice day! Cheers, Christoph -- Sent via mobile... Astron heinzless...@googlemail.com schrieb: Hi. I am probably sometimes out of my depth here, so bear with me if I propose unreasonable things. I had never used this feature until tonight. The main idea is now, that there is no difference between the currently selected element in the table above and the entries below. Example: If the user clicks on an element and starts changing the name, then this name will be changed live in the table above as well. Same for range options or the expression. So far, I like this. Still, a core point I would like to question about the current mock-ups is that there are a Define Names and a Manage Names dialogue. IMHO, there must be clever way of combining these. I'll try to think about an own mock-up. Some more core behavior: * If the user wants to add a new name from the Manage Names dialog, then we now go to the Add Names dialog (that makes adding new names really clear). * If the user changes a name / expression in the Manage Names dialog and this entry is invalid ... Can we restrict the characters that can be entered to the valid ones? Pressing an invalid key could simply result in nothing, except for maybe a slightly annoying beep (and non-modal information). * The user should be always able to exit the current change with ESC (restores last entry before the started to edit the field). Yes. And the change should be revertible with an Undo button (is that what the Back button is for?). * If the user selects more than one entry, then ... * we deactivate the text fields (maybe even the Scope field) * Paste (or Insert, no terminology decision yet) inserts all selected items. I hope I understand this correctly: it inserts the selected range names into the currently selected cell in a format like Cappuccino;Chocolate;Cookies? Then, I see two problems: # Paste shouldn't overwrite text when the current cell was double-click/F2-edited before opening the Manage Names dialogue (otherwise formulas might be deleted). Is that workable? # How is it possible to handle inserting multiple range names correctly? Some format work in certain formulas and when using certain ranges, some don't, i. e. neither Cappuccino+Chocolate+Cookies nor Cappuccino;Chocolate;Cookies is possible in all cases. Is clever guessing based on existing formulas possible here? * We could get rid of the Modify button - improves the number and meaning of the buttons Good. In the current interface it is used confusingly (not that there isn't precedent for this in other LibO dialogues – colour options, I am looking at you!). * Since we need to reserve space for the Information Text above the edit entries, we now can explain the user that he might also use formula expressions (if he adds a named range). For the rest, I strongly suggest to keep the common naming (for Calc and Excel users). Cool. But about the mock-up wherein two items are selected: you may beg to differ, but I don't find 2 range names selected to be very useful information. I think this one could go. * Once we do have non-modal messages, the Information Text line isn't needed anymore. Same info will be provided via message balloons (or similar). I find the majority of balloons to be aesthetically rather less pleasing and will fiercely defend the humble yellow-coloured information bar against attacks such as your own. :) A final note: Please be aware that this is something new to LibreOffice ... we currently don't have such a dialog concept, although I find it very promising. What do you think? Like it. Regards, Astron. _ 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] new range name dialog proposal
Hi Markus, officially, I'm not at the computer anymore :-) Therefore I'll try a quick reply ... Am Montag, den 24.10.2011, 22:53 +0200 schrieb Markus Mohrhard: 2011/10/24 Christoph Noack christ...@dogmatux.com: Am Montag, den 24.10.2011, 01:49 +0200 schrieb Astron: [...] From the technical point of view I don't like that idea. I think without loosing too much performance we can only synchronize two entries: either table-model or selected element- table. But then we have a big problem how we get the model into that. The problem behind that is that we should not change the model for every changed character while typing a longer entry. I think changing the name forces us to delete the old name and insert a copy with the new name and changing the expression forces a recompilation of the formula. Dumb question - what does loosing performance mean here? Do you think it might work if the table is updated after (one example) 300 ms of non-activity of the user (who stopped typing when changing the name)? So why the separation ... my aim was to let people easily and quickly add a new range name (there is a shortcut for calling that dialog). This Define Name dialog should only use very few screen space. The Manage Names is meant for organization / advanced use (non-modal). Originally, I even wanted to provide a simple way to switch from the Define Name dialog to the Manage Names dialog ... but I had to change the Manage Names dialog (so that Adding / Editing names becomes more clear), so that this doesn't work anymore. However, I still think that separation makes sense. Why don't we use this dialog for add and modify. I think we had that idea in our inital discusion in Munich. That would make it clear when we change something and we still have table and model synchronized. That's true ... but managing ranges does imply rather common changes like the range or the name of the range. At least Microsoft added a shortcut to rename items - I assume they did run into the same issue. The shortcut is an entry like featuring own accept/reject buttons. Something I had hoped to avoid... Some more core behavior: * If the user wants to add a new name from the Manage Names dialog, then we now go to the Add Names dialog (that makes adding new names really clear). * If the user changes a name / expression in the Manage Names dialog and this entry is invalid ... Can we restrict the characters that can be entered to the valid ones? Pressing an invalid key could simply result in nothing, except for maybe a slightly annoying beep (and non-modal information). Oh, my colleagues would love to have such a beep when working in an open-plan office ;-))) As far as I know, it is currently not possible to know the characters in advance, because the valid characters are influenced by localization settings and some other stuff. We may only know that something is wrong - any input has to be evaluated by the expression parser. I think I already implemented somenthing in this direction. I think the Add and the modify button are only enabled if the name is valid. I still think that allowing all characters and showing a warning that some characters are not allowed is better than too much magic that nobody understands. Do we know the characters being not allowed in advance? In my statement above, I guessed we don't know them ... that was my understanding in Munich. Invalid entries in the expression line are much harder to detect. I think these errors can only be detected if we compile the formula. How long does that take usually / worst-case? (just curious, I need to learn some new aspects) [...] Yes. And the change should be revertible with an Undo button (is that what the Back button is for?). Yes. I assumed that people might run into problems rather often, so Undo triggers (guess!) Undo. I placed it within the dialog, since this kind of non-modal dialog is rather seldom in LibO. Maybe it is not needed in the long-run. I like the undo inside the dialog much better that using global undo for that. The advantage of the old range name undo was that it just saved the state before and after executing the dialog. That made only one undo entry for several changes. Now we would have maybe 20 entries that are only created because we added range names or modiefied some of them. Okay, I need to think about that ... Undo is sometimes a bit neglected and is handled very differently. [...] Today we do have two options: * Insert one: the name is inserted (and if the user doesn't edit the cell, then the content gets replaced) * Insert all: a list of all names and their ranges gets inserted (I propose the same behavior for multiple selected items) Should we really keep the old behaviour for insert one? I know that as soon as I get the dialog non modal it might work but I don't
Re: [Libreoffice-ux-advise] [Libreoffice] Styles cleanup removing option page std fonts
Hi Dag! Am Mittwoch, den 19.10.2011, 22:37 +0200 schrieb Dag Wieers: On Wed, 2011-10-19 at 16:19 +0200, Dag Wieers wrote: [...] Are you volunteering ? (and it's worth checking the result with the ux-advise guys too of course). I am willing to help there, certainly ! But I'd rather have someone with some design skills come up with a generic color palette and styles that can be reused throughout documents, presentations and spreadsheets. Yep, a refined color palette is something we are missing, certainly. As far as I know, nobody proposed / volunteered to work on that. If you like, I can provide some hints how this was done in the past (for diagrams etc.). [...] One of the ideas I think would be great, is having a small LibreOffice logo on the default document somewhere on the lower-right of the page. Or in the default footer. The logo is stylish and non-obtrusive. Thanks that you like it :-) I do think this is perceived as way to much influence on our users' documents. PS I was very impressed with the default presentation stylesheet for the conference. And maybe green is a nice color for the default. Who did design that template ? Thanks again ... it was great community work :-) Starting point was - as usual - the LibreOffice visual branding. The conference logo and the motif (the pattern in the background) were made by Nik. I defined the remaining details - you may have a look: http://luxate.blogspot.com/2011/08/sliced-visual-design-time.html By the way, we now have a general LibreOffice Presentation Template based on that design: http://templates-test.libreoffice.org/template-center/libreoffice-presentation-templates Back to the defaults you've mentioned. If you chose to update some of them, please take some time to study what kinds of documents are created by users. The most helpful hint might be the OpenOffice.org User Survey 2009 Result available here (see Field Summary for EB7): http://wiki.services.openoffice.org/w/images/f/fb/OOoUserSurvey2009_Final.ods And, picking a question from one of your other mails ... Am Mittwoch, den 19.10.2011, 22:51 +0200 schrieb Dag Wieers: Any remarks/suggestions/tips at this stage? Can we collect some ideas and/or examples on the wiki somewhere ? For the admonitions (note, tip, important) I have some examples I really like from other Open Source documentation that I'd like to refer to. My proposal would be to pick a Whiteboard Page in the Design Wiki - there, we collect all the stuff e.g. in development: http://wiki.documentfoundation.org/Design/Whiteboard One example related to Writer: http://wiki.documentfoundation.org/Design/Whiteboard/Writer_SpecialIndicators You may create a page like (simply click on the link): http://wiki.documentfoundation.org/Design/Whiteboard/Writer_StylesCleanup Well, I hope some of the bits and pieces will help ... thanks a lot in advance for helping us! Cheers, Christoph ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Hiding/Showing the page breaks in writer
Hi Cedric, a few updates ... Am Mittwoch, den 28.09.2011, 09:14 +0200 schrieb Cedric Bosdonnat: On Tue, 2011-09-27 at 23:37 +0200, Christoph Noack wrote: Another small refinement - I think the current button interferes a bit (only a bit) with the shadow. From my point-of-view, could you move it a few pixels to the left? Well, it'll always interfere with something there... I even plan to make the button move with the page view to make sure we can always see it. In this case, I'd say we should keep its position constant - otherwise zooming/scrolling will make the page behave in a way that doesn't feel natural. To me, the header/footer was an exception, since you initially stated that people should be always be aware when editing headers/footers. But for the page break indicator, we have that nice line that's always visible ... people just need to follow that. The problem is mostly for the optimal zoom... in which you don't see the desktop margin and thus don't see the button. Otherwise I agree with you that it doesn't need to be moved. That being said, if we implement the mouse-over behavior on the line to show the button... then we can adapt it to the view. Ah, yes, that's true. Nevertheless, the current button might be something people don't want to see all the time ... if you remember my proposal [1] of having fade in / out functionality for the headers/footers, this can solve a bunch of problems here, too. For example, for column breaks the button may also just appear if the user hovers the red line (e.g. if not knowing what this is about). Same for the side by side view mode. The fade in/out thing makes probably more sense here than on the header/footers thing as the page break indicator is always visible otherwise. Fine for the page break, but some small refinement what I had in mind concerning header/footer: * full fade in / out avoids being suprised when the markup appears * intermediate fade in helps us to show the feature earlier, without bothering the user Ok. I'll implement it... but it's not the most urgent thing to do ;) True. On the whiteboard page, I've added another section that should contain the description ... or at least reminds us that there is something to do :-) Mmh, I think we (in terms of development) need the documentation of the fade in/out behavior ... but I think the basic functionality for the user should (soon) be fine. Please, all, if we think we're somehow finished ... then please remember to ping the other teams to make sure it will be a great LibO release :-) I'll ping them when it'll all be ready... still bugs and urgent things to fix in the new page breaks indicators. Cool! I've somehow completed the whiteboard page and send a ping to the Design List. Maybe we get some people reviewing the page, so that its reasonable to ease documentation and QA work. Ah, same would be cool for the people who already contributed (hint hint). I also exported the icon that shows the page break - the weird size is caused by the fact, that we need a symmetrical indicator and 16x16 items don't fit that well here. Since I did it the most simple way, please tell me if that's usable or not. You can find it here: http://wiki.documentfoundation.org/Design/Whiteboard/Writer_SpecialIndicators#Indicator_Design Okay, that was quite some stuff for header/footer/page-breaks during the last two days. I've promised to work on other topics as well, so I'll go (a bit) into suspend mode. Please tell me if you need something ... or if cool stuff (tm) happens in the daily builds ;-))) Cheers, Christoph ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice] Try to improve LibreOffice
Hi Dmitry, all! Am Mittwoch, den 07.09.2011, 18:10 +0400 schrieb Dmitry. A. Ashkadov: Hello! Can I try to improve LibreOffice? I had found task «Improving Saving Information Icon in the Status Bar» (http://bugs.freedesktop.org/show_bug.cgi?id=39430). Great! But I don't know who can help me, who can give me icons. The icons are part of the issue 39430 - there is a bug property called URL which refers to the TDF wiki. The link is: http://wiki.documentfoundation.org/File:Status-Bar-Saving-Info-icons.zip (Ah, just saw that Andras already added the link in a comment.) Since we talk about the icons: it would be great if you could exchange all the icons, since the unsaved changes icon seems to either be wrong or be wrongly scaled at the moment. Currently the contact in the bug (Paulo) is temporarily offline due to his studies - so feel free to contact me or anybody in the Design team. The best way to do that is to ping the Design Team is the mailing list libreoffice-ux-advise (no subscription required). More information at [1]. Otherwise, I've CCed myself on that issue. Thanks for you help! :-) Cheers, Christoph [1] http://wiki.documentfoundation.org/Design#Communication ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Additional info (was: Re: [PUSHED] thereof should be translated to modern English)
Hey Caolán, hi Lior! I just noticed this discussion, so here some additional remarks. Cool, it seems you've addressed one of my ancient undecided items ;-) Am Montag, den 05.09.2011, 14:33 +0100 schrieb Caolán McNamara: On Mon, 2011-09-05 at 13:10 +0300, Lior Kaplan wrote: The calc print window uses has There of. Although correct English, it seem not to be the best choice of words. See http://listarchives.libreoffice.org/global/l10n/msg03013.html The following minor patch tries to fix this. Any rejections ? Looks reasonable to me. Pushed now to master. When working on the printing topic, we've did several string review iterations for the new dialog. For English, Liz was so kind to support me (Liz is the author of the OOo terminology style guide). The discussion item: The sub-group name Thereof print seems to be an issue because of the mixture of nouns and verbs. Liz proposed Withing the print range, print:. @ Lior: Do you think the proposal by Liz might fit better (and does meet l10n requirements in terms of length)? Otherwise, I'm fine (and thankful for your tweak). For details (further proposals and the complete string review): http://wiki.services.openoffice.org/wiki/Printerpullpages/String_Reviews The most recent printing UI mockup incl. string review markups: http://wiki.services.openoffice.org/w/images/9/94/2010-01-17_PrintingDialog_inclStringReview.png Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Additional info (was: Re: [PUSHED] thereof should be translated to modern English)
Hi Lior! Thanks for your lightning fast reply ... Am Montag, den 05.09.2011, 19:51 +0300 schrieb Lior Kaplan: On Mon, Sep 5, 2011 at 7:43 PM, Christoph Noack christ...@dogmatux.com wrote: Looks reasonable to me. Pushed now to master. [...] @ Lior: Do you think the proposal by Liz might fit better (and does meet l10n requirements in terms of length)? Otherwise, I'm fine (and thankful for your tweak). I tried to keep the string as short as possible. Your/Liz's suggestion sounds OK, but I think it's a bit long (trying to visualize it on the dialog). Anyone has another opinions on this ? Oh, let's simply keep the new string if it fits from you point-of-view. My main aim was to hint towards existing information that might have been helpful here. Concerning the latter, it would be great if you could CC the mailing list libreoffice-ux-advice if (hard to discuss) string proposals pop up. Maybe we/I can provide hints to discussion from OOo UX times. Since I have another question, I'd like to move that discussions to that mailing list (no subscription required) and like to ask you, whether a terminology database / glossary is available for UI stuff. Is this something the l10n team is working on? Terminology is terribly important and it would be immensely helpful for UX / UI stuff to have a shared resource for Documentation / Translation / Design. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Restoring the slide names in the Slide pane? (was: slide names in Slide pane Impress)
Hi Thorsten, thanks for the pointer! Am Montag, den 22.08.2011, 17:56 +0200 schrieb Thorsten Behrens: Cor Nouws wrote: [...] Apart from /besides the ideas and questions above, I think it is important to ask the UX list about their ideas. Well I guess that cannot harm, presumably the removal of the title was by purpose - maybe Chris et al. remember the details. More ptrs in the bug, I'd suggest. Chris, UX team: this is about bug https://bugs.freedesktop.org/show_bug.cgi?id=37654 - seems users want the slide name back. :) I've added the information I have - seems that the redesign of the slide sorter(s) in the Renaissance project made the names disappear. Pointers to bug and spec in the comment: https://bugs.freedesktop.org/show_bug.cgi?id=37654#c10 What I've additionally noticed is that there is a mouseover (tool tipp) showing the name of the current slide. And of course, we don't talk about the slide pane only - its also related to the slide sorter. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Suggestion and patch for Confirmation of save format dialog
Hi Josh, Astron, all! Astron, although you've already replied to this mail (thanks!), I'd like to pick one point from Josh - there is nothing more I can do today ;-) Am Montag, den 15.08.2011, 22:41 +0930 schrieb Josh Heidenreich: [...] ... Without a good reason, it is not much fun to break the user's his workflow. So my proposal is to go ahead as soon as possible ... and discuss such non-modal dialogs we need (and miss) quite frequently. In our case, it could be saving to WhatEver format and then telling him afterwards (for a few seconds) that ODF might have been the better format. We have to be careful to not be condescending to the user though, or make them feel bad or guilty that they chose the wrong format. There is plenty of reasons to choose a non-odf format. Maybe some misunderstanding at this point? In my opinion, the today's dialog already tells our users that ODF is the better format - without any good reason, because we don't really know. Really, I think we should all remember two things: 1. The best way to fix this dialog is to have the filters do a better job of saving in other formats. If it only came up for formats which actually destroyed formatting, like TXT, wouldn't that be great? We should always keep that as a primary goal rather than this dialog. Yep, I totally second that - but that requires some changes within LibreOffice/OpenOffice.org. The two things I've noticed over the years: there is still misunderstanding/confusion what this dialog is about (or why it disturbs without any good reason), and the technical limitation of identifying serious issues (like destroyed formatting). Because of the latter, people (including myself) had to work around those technical limitations - resulting in this dialog, ambiguous clues, broken workflows. Although we're not solving the root cause (which I'd love to do), it is still better than people having screwed up documents. 2. This shouldn't be seen as an attack on developers of other projects, but there have been recent large changes in the Open Source/Free Software world, in regards to UI design (and also in propriety software), which have brought a lot of complaints for no reason. Lets not make changes for the sake of making changes. I'm not going to point the finger or anything, but I have noticed a lot of outcry about Gnome 3, KDE 4, Office ribbon, Ubuntu, Firefox, etc. It seems to be popular at the moment to just make changes for the sake of it, and it really confuses and often annoys users. I'm not saying these projects are bad or we are going in the wrong direction, but we all need to vigilant to ensure we don't make fatal UI mistakes, and while non-modal may seem like the best thing from a UI design perspective, if it's not what users are expecting, it's still no good. Wow, this would require a multi-dimensional answer ... but I don't know whether this helps, since it seems to me that we are both on the same side. Changes for the sake of change are bad for those who rely on consistency and stability - especially in our office productivity world. The word productivity is important here - the aim is to make working with the software more efficient. And there is much we can do (good and bad). All of the products you've named do have some excellent UI solutions ... and some introduced issues people are (for good reasons) unhappy with. So the simple answer (example) is: design, test, iterate, ... implement it for production use. Well, that requires time, skills, tools, and dev support. And sometimes the right framework. Concerning our initial discussion about the Confirmation of save format dialog, here is one example: the non-modal messages. Every month, the answer on an issue is to turn it into non-modal feedback. Every month it is said that for that (single) problem it is not worth the effort. So, every month we go for a sub-optimal solution. Since years. I consider this a real issue ... although the possible solution might have changed over the years ([1] shows a design I've started 4 years ago, scroll dwn, please). Looking forward - what can we do? (My answer: go to sleep *g*) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Suggestion and patch for Confirmation of save format dialog
Hi Josh, Regina, Astron! Josh, thanks for the patch and the screenshot - the latter makes evaluating things for less developers (tm) like myself very quick and easy. Am Donnerstag, den 11.08.2011, 12:29 +0930 schrieb Josh Heidenreich: Hi All, I have made some additional changes to the dialog. I am considering these changes stage 1 of the process. Screenshot: http://thejosh.info/libreoffice/export_format_v2.png I have attached a patch also. Already an improvement, I think. Since I lack a bit time this morning (should already be on the way to improve usability at work *g*), I want to just add some details to my initial proposal. Concerning the buttons - similar to Astron, I thought about using the document file types both in the text (full description plus file extension), and in the buttons (only the extension) - but we just turn the understandability problem into another one. Hence, my question whether a semi-automatic extraction of short versions of the file type will work for buttons, e.g. n=20: * If the length of the description is = n, then use the full description. (Microsoft PowerPoint -- Microsoft PowerPoint) * If the length of the description is n, and the first n characters contain several words, then use all whole words in this n characters. (HTML-Document (OpenOffice.org) -- HTML-Document) * If the length of the description is n, and the first n characters contain one word only, then use the first n-3 characters and add ... (don't know any example, just for stability reasons) Mmh, although it makes the code more complex - it would at least allow to use all mechanisms and data we have to provide something meaningful in the dialog ... although I'm for simple solutions, I think it would be helpful for those use cases I'm aware of. Another thing I've thought about is keep, use anyway, ... Only the visual marker on the button reveals the default choice in the dialog (grrr, different to LibreOffice ODF default - didn't notice that) - so my take is to address this via: [Use WhatEver Format] [Switch to ODF Format] Last question: I know that almost no message box makes use of it - but is there a chance to turn the header text into something useful? Cheers, Christoph PS: Since you've started to discuss the message boxes, I see this as a chance to document general design recommendations afterwards. So sorry and thanks at the same time for your precious time :-) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Suggestion and patch for Confirmation of save format dialog
Hi Noel, Josh, all! @ Noel: Thanks for forwarding! @ Josh: UI designers at work being LibO users? We should definitively meet on the Design Team list ;-) Am Dienstag, den 09.08.2011, 10:31 +0100 schrieb Noel Power: Forwarding this to the ux-advise list, a better forum I think for discussion about such changes Noel On 09/08/11 00:45, Josh Heidenreich wrote: For a long time I have been annoyed at the Are you sure you want to save as a .DOC message, as I find the buttons confusing. True, true - I think this issue came up each year twice during the OOo times. As far as I know, there have been numerous attempts to fix the understandability of the buttons ... First, thanks a lot for taking care about that. Although I think the dialog needs a bit more tweaking, it is a step towards the (very) right direction. I have made some changes, with the button to show the format name. Screenshots: http://thejosh.info/libreoffice/export_format1.png http://thejosh.info/libreoffice/export_format2.png I have coded a patch, although it's against the old repos. As far as I can see, nothing changed but the button layout and their caption. Right? Unfortunately, I think that: * the (possible) length of the button text, and ... * the stacked button layout (which is never used in LibO that way) will eat up the improved understandability of your change. So, what do we have to fill the buttons when exporting (if we want to get back the usual layout)? I assume there are: * the file format description Microsoft Word 97/2000/XP/2003 format * the file format extension .doc Is there something else available within the code/data, e.g. only Microsoft Word format? Is there something we can do to limit the length of the buttons? Given the file formats we have, I think 20 characters containing whole words should be sufficient (e.g. for Microsoft PowerPoint) to cover all major use cases (in English, needs some refinement). Some other things being strange: * I assume that the message Do you want to save the document in this format anyway? refers to some older Yes/No buttons. We may update that as well. * People might not know what ODF refers to. Usually they see odt or odc ... if they see that. -- trying to make it the LibreOffice default file format * The latest ODF file format is nice, but something for experts - especially since the user may wonder where to set the latest ODF file format in this dialog. * The position of the file format description makes the text hard to read - moving it to the end. This leads to ... (non-native English speaker brainstorming) ... == The document may contain formatting or content that cannot be saved in the currently selected file format Microsoft Word 97/2000/XP/2003. Use the default ODF file format and be sure that the document is saved correctly. [Use Microsoft Word Format] [Use Default ODF Format] -- [x] Ask when not saving in ODF format == Is this something which could be turned into reality (=code)? What do you think? Interestingly, the dialog does not provide any further help ... strange. Wondering whether we should ping the documentation team. That said, the most helpful thing (but most difficult) ist to tell people what will be missing exactly in terms of content, features or formatting when exporting documents. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Handling EasyHacks in general (was: Re: [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167)
Hi Gerald, hi all! Am Samstag, den 06.08.2011, 19:04 +0200 schrieb Gerald Leppert: Hi Friedrich, hi all, does anyone here have a less rigid opinion on that matter than the one expressed by Friedrich? I really don't care whether you want LibreOffice to be a developers AND users community or whether you want to separate these two from each other; whether the LibreOffice community is welcoming or not. Well, I don't feel comfortable to comment Friedrich's statements - its rather the opposite of what I feel makes this project progress. So I'd like to state what happened to me so far. In the past, we (the Design Team) have been asked by some developers to collect usability issues and add those to the Easy Hacks. That's great, since (I hope) that new developers are (also) attracted to solve those issues that really hurt users. Whenever I've intended to add an Easy Hack (means: before or after adding it to the issue tracker), I've asked a developer to have a look at it, because: I feel confident with regard to UX matters, I know some basics how LibO/OOo works, but I have _no_ clue about the internals. Every time, I've got a friendly and helpful reply ... But: I've pinged those devs which I know personally, that's something which a) might bother them in the long run, and b) isn't suitable for the rest of the community. Sometimes, some more opinions are needed when addressing EasyHacks ... e.g. documentation, QA or UX. I think that's something every developer will agree to. Consequently, the underlying tool (issue tracking) is used to enrich the hack with additional information (assuming that its helpful). That might lead to some confusion what he Easy Hacks approach is used for: * collecting / filtering Easy Hack proposals * assigning / tracking Easy Hack * QAing / documenting changes due to Easy Hacks I only would like to know how users are allowed / should / can contribute to the EasyHacks-system. I am confused, because the original EasyHacks wiki page did not carry any restriction on who may contribute to it and my interactions with others on that matter had been always positive. Also, the definition of the tag [ProposedEasyHack] is defined as As task that is thought to be easy to hack, but has not been checked by a developer to not contain nasty surprises. Please advise. Very good questions ... it would be cool if some of us (QA, dev, UX) could chat about that (Hackfest in Munich, anyone?). At the end, Easy Hacks is only one way how an issue / wish is turned in something a new developer may work on. I'm sometimes also unsure how to handle Serious Hacks, even strategical stuff. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167
Hi Gerald, Kohei, Jenei ... all :-) Disclaimer: My hybrid PDF stuff in LibO seems a bit broken, so some things can't be tested ... please point out things that work already. Am Freitag, den 05.08.2011, 15:22 -0400 schrieb Kohei Yoshida: [...] I'll leave the specific enhancement request discussion to the UX folks, but let me address several of your expectations below. Okay, here are some initial thoughts - but first a short summary how I understand Gerald's request: * Hybrid PDFs are an important feature to him (option should be moved to the top) * The naming hybrid does not provide too much clues to the user (caption change proposed) * Identifying hybrid PDFs is close to impossible, because OS don't support that properly (file type name) * Opening hybrid PDFs for editing (again) is harder than necessary (recent files list) Correct? On Fri, 2011-08-05 at 16:59 +0200, Gerald Leppert wrote: [...] Improvements to hybrid PDF: As mentioned in the bug 39168, the hybrid PDF feature is one of the killer features in LibreOffice. However, its implementation has some practical and usability problems out of those most had been already raised in the OpenOffice.org bugzilla. However, most of them can be easily improved in terms of usability and handling. This was my intention of the three enhancement requests made to hybrid PDFs (bug 39167, bug 39168, bug 39169) and I was glad that Gabor liked the idea and took the initiative to start working on two of these easy hacks. Lets try to get a better overview - here are some initial thoughts: * The name Hybrid PDF is indeed a bit technical. A different short name (e.g. Combined PDF/ODF or Embed ODF source file) and revised description (advanced help) are indeed helpful -- but: for the dialog caption, please respect the text width required for translation * I don't know if hybrid PDFs are one of the killer features, because ... * Portability: Conforming to standards like PDF/A-1a seems more important (in terms of arranging the options) * Size issue: PDFs are today used to deliver documents to mobile users (plain PDFs are still important) * Feature Set: Using hybrid PDFs removes the export page range feature * The current hybrid option requires the PDF import extension - being optional (although being shipped on e.g. Windows) makes it a less important option * There is a major difference for the user between exporting documents (editing in LibO causes major loss in fidelity / is impossible) and saving files (runs smoothly) -- your proposals would require LibreOffice to treat hybrid PDFs similar to native file formats * Opening of a (non-hybrid/hybrid) PDF should be possible in any application. If it is a non-hybrid PDF, then inform the user that it gets imported in Draw; if its a hybrid PDF, then simply open it * Re-opening a hybrid PDF and saving it again should create an updated version of the hybrid PDF * If possible: if a hybrid PDF gets saved, then inform the user about the consequences (might look like a normal PDF, size, ...) * Side note: for the hints, the non-modal information bars would again be helpful * I share the concerns stated by the others with regard to the .od?.pdf file extension - especially since most people might still not know what the od? stands for. I'm unsure about the real impact. An alternative may be to change the given file name to something like -embeddedODF.pdf. Users might then consider to change that manually ... A last question from my side: What happens if e.g. a hybrid PDF gets opened in Adobe Acrobat and saved again. Is the ODF preserved, even if the PDF got changed (e.g. comments added, pages removed, ...). If yes, then it makes things a bit more difficult (according to user expectations). Well, I hope some statements are helpful to continue the discussion and to get some feedback on the feasibility of the proposed changes (especially the treat it like a native file format). Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Reviewing EasyHacks (was: Re: [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167)
Hi Jenei! Am Freitag, den 05.08.2011, 22:37 +0200 schrieb Jenei Gábor: And to avoid the further misunderstandings I recommend to review all the easyhacks before publishing. I'd like to hijack this thread a bit, since you address something important (to me). So, adding Björn and Rainer to this thread. My question is who should review the Easy Hacks before publishing - when looking from the Design Team perspective, it would be good to at least add a UX (User Experience) statement whether the Easy Hack is helpful or not (not may also mean that a different solution would be even more helpful by resolving some more issues). Personally, whenever I got aware of such Easy Hacks (more by accident than by using a systematical approach), I've added such statements. Some weeks ago, I had a short private discussion with Björn how Easy Hacks could be marked if we (in terms of the Design Team) think that some hint / further thinking might be required. Sorry for not discussing this earlier ... pushed that forward all the time :-\ However, the question was if additional (whiteboard) tags like UxSimplyGo or UxGetAdvice might help. These tags could be added in QA bug hunting sessions, or by a regular review of such tasks by the Design Team. In the meantime, I also got sometimes added to be the ux contact for other issues ... Might the tag solution be helpful? Or are there other ideas / proposals to make it even easier for developers to simply grab Easy Hacks? Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] [REVIEW 3.4] FindBar silently reuses options from the Search Replace dialog
Hi all! Kendy, thanks for this initiative :-) Am Mittwoch, den 27.07.2011, 19:35 +0200 schrieb Cor Nouws: Hi Kendy, Jan Holesovsky wrote (27-07-11 00:51) With the patch I am proposing for cherry-picking to 3.4 (I have pushed that to master), the options are unset when you use the FindBar, ie. it Fine for me as temporary solution! The annoyance of not understanding what happens with the Find bar is larger then the problem of having to set options again .. True. Plus, what IMO is more important ... resets whatever flags the user has set in the Search Replace dialog too. This is not easy to fix, so I wonder if you consider this stop-gap solution bearable for the users? Kendy, you mention is not easy to fix - what do you mean here? Setting back the options in general, or (maybe) making find bar and findreplace dialog work independently? ... is the older discussion from ux@ooo (1) and an/more issue (2), about the unexpected, invisible reuse of options previous set in the FR dialog and some inconsistencies/debatable choices made in the implementation. Would be useful I guess to at least consider those too, before touching the code for a real solution. Okay, before offering some ideas, here are my assumptions: * the find bar will be used for straightforward search only (thus: it should not adapt / implement the searchreplace dialog exclusive items) * both dialog bar and findreplace dialog won't be visible at the same time (currently the daily build doesn't work for me ... so I can't check how it works at the moment) * If the findreplace dialog is opened for the first time (in this session, for the given module), then defaults are used that don't enable anything in the More Options panel * The findreplace dialog is rather complex and people might also have issues to default all the setting easily If some statements appear weird - please feel free to correct me! So my proposals: * The findreplace dialog should: * ... either: show the More Options panel state when re-openend and more options have been changed -- as suggested by Cor * ... or: restore the More Options panel state when re-openend (e.g. show it, if it was shown before) * ... and (optional): visualize if more options are changed even if that panel is closed (e.g. needs some thoughts) * The shared find bar options and the findreplace dialog options should be synced (the last used element sets the options / find / replace strings etc. of the other element). All non-shared elements (here: only relevant for the searchreplace dialog) are reset to defaults. * The findreplace dialog should get a Defaults button to reset all the control elements in the dialog [optional, recommendation] Mmh, it seems that should be added to the whiteboard page - agreed? Did I miss anything? http://wiki.documentfoundation.org/Design/Whiteboards/Find_Bar Side-note: There are still some unanswered questions, e.g. the complexity of the searchreplace dialog and the relationship with the navigator buttons ... this requires to think about the features on a more generic level. Regards, Cor 1) http://openoffice.org/projects/ux/lists/discuss/archive/2009-10/message/8 2) http://openoffice.org/bugzilla/show_bug.cgi?id=88714 Thanks for bringing that up! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO Custom properties
Hi Swagat, sorry, no code help - but the hint that there is a specification that describes what kinds of properties can be added. Unfortunately, the spec doesn't cover file handling or migration issues :-\ http://specs.openoffice.org/appwide/fileIO/Custom_Document_Properties.odt Maybe it helps ... but I fear it doesn't. Cheers, Christoph Am Donnerstag, den 21.07.2011, 09:15 +0530 schrieb swagat sharma: Hi Michael, Thanks for your valuable time. I'll explain the problem in more details. I create a new Document (.odt file). I add some custom properties, Say a text and a number, by going into File-Properties-Custom Properties. I save the file (as .odt) and close it. When I open the file, I go to custom properties and they are there. Now I save the same file as Microsoft 97/2000/XP format, using 'Save As' option. I close and reopen the .doc file again.. All the Custom properties are vanished. So I just want to know how libre office handles the Custom properties, which all files are involved. I just need a little start up. Its really bottleneck for me. Your help will be highly appreciated. Regards -- Swagat On Wed, Jul 20, 2011 at 4:05 PM, Michael Meeks michael.me...@novell.com wrote: Hi Swagat, On Wed, 2011-07-20 at 15:14 +0530, swagat sharma wrote: I am working on fixing the custom properties in libre office, which are not preserved in MS format. Sounds good - can you be more precise as to exactly which properties you're talking about though ? :-) I need little help as I have never worked on LO or OO before. Can I know which all files are involved, or deals with custom properties. So - more details apprecicated. Also how do we convert an .odt into a MS .doc. On the command-line; ./soffice --help will help you wrt. --convert-to etc. The core code for the binary .doc filters is in sw/source/filter/ww8/ HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [MHST][Easy Hack] Get current page number for printing
Hi TaTung, all! Sorry for answering so late ... Am Samstag, den 16.07.2011, 21:40 +0700 schrieb Ta Duc Tung: On 07/16/2011 07:29 PM, Christoph Noack wrote: [...] We are trying to hack into this easy hack https://bugs.freedesktop.org/show_bug.cgi?id=38830 We're still studying source code. We have 2 questions: Great! [...] 2. How to add another RadioButton in to print dialog? We can enable and disable existing RadioButton like All, Pages, or Selection but it's still mystery for adding new RadioButton. We want to add a Current Page radio button just below Pages radio button. Anyone please help us :) Is there a specific reason to use another radio button? OOo once added the current page number to the Pages field - which worked okay for many users. I think it will be more intuitive and easier to use if we have a Current Page radio button there. As a beginner, I won't aware that the number in the text box is current page because normally, I scarcely care which page I was. Okay, that's a good point - when we've designed the today's printing dialog, we tried hard to get rid of many of the old options to make it both useful and clean (although current page was never part of that). I've noticed that you already provided a patch for that - thanks! And here I'd like to ask you to help me to get some understanding ... reason: I lack C++ coding skills. So ... * Where is Current page located? Between Pages and Selection, I assume, or? * Please take care that the dialog does not grow in height (too much), since it won't be usable on netbooks. * Does this patch also provide Current Page for Draw/Impress? This would be essential for consistency. If yes, then the terminology for Impress only) is different: Current Slide. Only for Calc and Math it is not needed or makes less sense. Could you please provide some hints to me? Thanks! Mmh, looking at a recent LibO version, I notice that somebody moved ... the reverse order option to a weird position (makes no sense, breaks spacing etc.) But that's another story. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [MHST][Easy Hack] Get current page number for printing
Hi TaTung!, all! Am Samstag, den 16.07.2011, 16:02 +0700 schrieb Ta Duc Tung: Hi, We are trying to hack into this easy hack https://bugs.freedesktop.org/show_bug.cgi?id=38830 We're still studying source code. We have 2 questions: Great! [...] 2. How to add another RadioButton in to print dialog? We can enable and disable existing RadioButton like All, Pages, or Selection but it's still mystery for adding new RadioButton. We want to add a Current Page radio button just below Pages radio button. Anyone please help us :) Is there a specific reason to use another radio button? OOo once added the current page number to the Pages field - which worked okay for many users. And Word, as far as I remember, also handles this a bit different (if we look for easing the transition from MSO users to us). Thanks for working on that! Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Don't default to 'Selection' in the print dialog in Writer
Hi Jonathan, all! Am Donnerstag, den 14.07.2011, 13:17 +0200 schrieb Jonathan Aquilina: On 14/07/2011 13:14, Jan Holesovsky wrote: Jonathan Aquilina píše v Čt 14. 07. 2011 v 12:45 +0200: This is exactly the behavior I had reverted from the reasons I have described; to summarize: somebody who wants to print a selection knows what she wants to achieve, but somebody who selected something by mistake does not notice the default is to print selection, and is confused. Re reading what you said here, then set default like the web browsers do and print whole document and if the user knows what s/he is doing then they can take a sec to click on selection instead, no issues what so ever and all parties are satisfied. Kendy, thanks for the fix, as I already pointed out in our discussion on the libreoffice-ux-advice list. But, Jonathan, I doubt that we'll please all parties - especially with regard to printing. Printing whole documents (which can be much larger than web pages) is about time and costs - accidentally printing 200 pages is a mess, especially since average users are unable to stop printing either in the OS or on a printer (anybody tried this on a MFP?). Earlier you proposed to show a warning - and Kendy said these aren't read. Well, I think it is about balance between information and bothering. There are also other circumstances where hints would be beneficial. When I've worked out the today's printing dialog, I created a proposal how to solve such in-dialog message needs. The wiki page: http://wiki.services.openoffice.org/wiki/Printerpullpages/ContextualInformation The mockup (the quick link): http://wiki.services.openoffice.org/w/images/6/6c/PrintDialog_ContextualInformationBar_GeneralDesign.png So, dear developers, does this look interesting to you? ;-) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Are we back to having this spec process again!?
Hi Kohei, you know that I'm both subscribed to this bug, so I feel free to comment on this - rather from the UX point-of-view (although I know some people from Documentation, QA, ... who think similar). Am Samstag, den 09.07.2011, 13:39 -0400 schrieb Kohei Yoshida: Regarding this bug https://bugs.freedesktop.org/show_bug.cgi?id=39068 Rainer started the specification process for this. I'd like to say that he offered to write a specification - which is a bit different from a full-fledged process. Isn't it positive if somebody (whoever this is) cares about collecting the information if the complexity of the issue avoids handling all inside a simple bug report? Especially if nobody urged him to do so - he already invests a lot of time for LibO. As Rainer stated, some of the changes do affect some rather fundamental definitions within the help - how should the Documentation team know? And the different example documents showed (at least for me) that separating the issue from the intended behavior is difficult. If we change that behavior - how should QA know what to test? I thought one thing we decided to do was not to re-introduce this over-engineered, time-wasting specification process. Is this a new development in the LibreOffice space? I welcome if people announce / describe some of the intended changes without major changes in the visible functionality. But, I currently perceive a lot of doubled work outside the development team due to the lack of information. There are also some examples within Calc where such a lack of information requires a lot more time for UX and Usability work (although we lack developers, currently it is Development Power UX). However, bothering the developers for details about the intention, the detailed behavior or having fundamental discussions in the issue tracker after a change has been introduced - I think that's tedious for developers as well. We should avoid that. Not to mention I'm very disturbed by this. I'm sorry that you feel like this - I'm sure this wasn't intended by Rainer. But I have to admit that some people (myself included) / teams feel irritated by lacking information (in advance). Maybe this is a good starting point to re-think how non-trivial changes are worked on ... switching from Easy to Serious Hacks :-) Any interest? (Also on another list, in a conf call, or ...) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Style And Formatting window
Hi all Cor, hi all! Am Mittwoch, den 06.07.2011, 00:44 +0200 schrieb Cor Nouws: [... Style and Formatting Window behavior ...] Well, while were are at thát ;-) pls add a button for (un)dock! Well, while we are at that ;-) If somebody searches for an less easy Easy Hack ... some time ago, I invested some serious thoughts in how task panes could look and behave like. An draft is shown in a graphic at: http://uxopenofficeorg.blogspot.com/2010/01/ux-meeting-in-hamburg-day-two.html Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Style And Formatting window
Hi Caolán! Am Mittwoch, den 06.07.2011, 15:55 +0100 schrieb Caolán McNamara: On Wed, 2011-07-06 at 00:26 +0200, Christoph Noack wrote: Well, this question may open a can of worms, so to say. Omitting all the explanation it finally leads to (from the user's point-of-view): Is LibreOffice an office suite that behave consistently and works with different file types?, or Does LibreOffice bundle several rather separate modules?. Both approaches do have pros/cons - but it should be clear, because it would solve lots of other questions. IMO we should be consistent, but not to the degree that it gets in the way, 'A foolish consistency is the hobgoblin of little minds' :-) Sure, and this is the magic ... the decision on what should be consistent (for ease of learning / switching between the modules) and what may be adapted for special use cases (making things more efficient). However, what I also had in mind was how LibreOffice is presented to the user. Some years ago, we talked about StarOffice being able to handle different document types. Then, the single modules got emphasized to compete with Microsoft Office which was marketed in a different way. Since then, we really suffer from this unfinished transition ... so whatever we do, I'd like to decide in the near future what our aim is for LibreOffice. Mmh, but this might rather be something for the marketing list ... Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Style And Formatting window
Hi Caolán, hi all! Am Dienstag, den 05.07.2011, 09:18 +0100 schrieb Caolán McNamara: On Tue, 2011-07-05 at 09:32 +0200, Cor Nouws wrote: James wrote (05-07-11 07:56) When you turn on the Style And Formatting win with F11 in Writer, is it supposed to be open in Calc? I find it very annoying to be on in Calc. It is very useful in Writer but not very in Calc. Yeah, this bugged me for ages. Personally I'd like the style and formatting window in different modules like writer and calc to use different per-module settings for their position, docked/non-docked and shown/non-shown. As you say styles and formatting is far more useful in writer than calc, and I like styles and formatting to be shown and docked in writer, but not shown in calc by default, and when I do want to see it there I would like it to be a normal floating window. Well, this question may open a can of worms, so to say. Omitting all the explanation it finally leads to (from the user's point-of-view): Is LibreOffice an office suite that behave consistently and works with different file types?, or Does LibreOffice bundle several rather separate modules?. Both approaches do have pros/cons - but it should be clear, because it would solve lots of other questions. However, I do understand the general idea ... although I think that we should stick with a rather simple behavior to ease the understanding for the users. Having too fine-grained individual settings might make things worse, so here is the proposal: * per-module setting for shown / non-shown * default setting for shown / non-shown is kept * same behavior for all similar windows (e.g. Gallery, Database, Navigator, ...) * instead of a per-module setting for docked / undocked, these windows really need a closer button when docked (similar to the task pane in Impress). Mmh, by the way, how does LibO handle if there are separate windows (e.g. Calc) having different settings for such a window (e.g. docked / undocked). Which one will be the new default if LibO is completely restarted? Thanks! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Status of unlimited conditional formatting
Hi Kohei, sorry, I don't know the current status - the last mail I'm aware about is dated 20.04.2011 01:18:33 ... Rob mentioned that - concerning the new stuff - he can't work on it these days but I will try to propose something in the begining of may. Agree, would be cool if there is a chance to continue this great work! Cheers, Christoph Am Montag, den 13.06.2011, 19:03 -0400 schrieb Kohei Yoshida: Hi there, I'm just checking to see if there is any activities on Robert's nice unlimited conditional formatting rework. I had thought that this already went into master, but then I just checked realized that the dialog looks the same as before (i.e. only supports up to 3 conditions). Has this been stalled, or did this go in but somehow accidentally got reverted, or ... ? I'd love to get this piece included I'd hate to see this work go unhandled. Thanks, Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removes find/replace dialog button from standard toolbar
Hi Caolan, hi Sam! Caolan, I think the proposal by Sam will work well ... and if we need a button, then it should rather open the search toolbar. For the next step in the Evolution of Search (tm) I proposed to provide the SR-Dialog via an Advanced ... button (the final naming may differ), see: http://lists.freedesktop.org/archives/libreoffice-ux-advise/2011-June/31.html So, if we can improve the find bar a bit, the overall experience should be greatly improved. Cheers, Christoph Am Dienstag, den 14.06.2011, 07:30 -0700 schrieb Samuel Cantrell: Caolán, It's true that the find button allows for access to the find/replace dialog, which allows more functionality. Do more people use the find button, or use the menus to find the find/replace dialog though? I know I use the menus, however, it would obviously be fallacious to assume that my use-case is the majority one. I did only hide the find button so that any user could add it back to the toolbar if he so wished. Thanks for your comment! Samuel Cantrell On Tue, Jun 14, 2011 at 7:09 AM, Caolán McNamara caol...@redhat.com wrote: On Sat, 2011-06-11 at 07:35 -0700, Samuel Cantrell wrote: These patches remove the find/replace dialog button from Calc and Writer (per http://wiki.documentfoundation.org/Development/Default_UI_Improvements). As we have the new find toolbar, these buttons seem unnecessary. hmm, well the find toolbar only finds, while the button to launch find/replace allows replacement as well. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] style selector / abandonware ...
Hi Michael, cool, looks like a _very_ promising start :-) Am Dienstag, den 14.06.2011, 11:04 +0100 schrieb Michael Meeks: Hi guys, I have to task switch for a week or so now, so I just dumped my latest (hackish) re-hash of the style preview / selection pane I was working on here (click the navigator paint-can): http://people.gnome.org/~michael/data/2011-06-14-style-preview.diff It looks like this: http://people.gnome.org/~michael/images/2011-06-14-style-preview.png Okay, so at the moment it is just a matrix like preview in a separate window. Each of the previews seems to render the name of the style in 100% size, centered. Correct? I had a few questions: a) ux guys - would you like a side-bar a bit like this ? could we make that a 'mode' of the style navigator ? + what interaction modes would work well here: mouse-over style preview ? Some QuickThoughts (tm): * Toolbar Drop-Down for Paragraph Styles (m x n matrix instead of a plain list) * Paragraph Styles in the Stylist (preview for each list entry, for all modes but hierarchical view) * Character Styles in the Stylist (preview for each list entry, for all modes but hierarchical view) Of course, the devil is in the details - we want to keep this list manageable (size, number of items), the styles (easily) editable, the stuff accessible (keyboard nav etc.). So, these thoughts are a start, I think. + context specific style/palette adaption ? Mmh, what do you have in mind - we already have some (more or less working) context specific context adaptations in the Stylist. b) any more thoughts on that ? c) since this is essentially a stolen (re-factored) 'preview' widget from the existing 'style' dialog - I wondered ... are there other easy-to-steal preview widgets that we can re-use to make applying these things easier ? [ perhaps border selectors ? ]. Mmh, don't know whether this fits technically (we'll need that anyway, soon *g*), but how about the new toolbar drop-down selectors in Impress. See: http://www.youtube.com/watch?v=WnfZlYU0SNc (interesting part starts exactly at minute one). Furthermore, the slide sorter preview, or the master slide preview might be other candidates. d) Do we have an enterprising hacker wanting to play with creating a more attractive navigator / style pane here? + it is slightly complicated due to the shared nature of sfx's style code between all components Thoughts ? Hackers? :-) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removes data sources button from standard toolbars in Calc and Writer
Hi Alex, hi Samuel! Am Sonntag, den 12.06.2011, 10:22 +0200 schrieb Alexander Thurgood: The data sources explorer is still accessible from the View menu, and my patch didn't affect that. I agree that data sources are useful. I don't necessarily agree that it's necessary to have an extra button on the standard toolbar that users have to decipher its meaning so they can find the buttons they want. Often a clearer or more significant icon will do wonders, but that is just my opinion, I'm not an UI designer. I think what the author of the original idea (remove that button) meant was, that most people simply don't use that functionality - in such cases a more significant icon won't help (then, we would need approx. 500 more significant buttons). Quite the contrary, since such changes might interfere with the more often used features. Of course, this is not the only hypothesis - maybe the functionality doesn't work well and people don't use it, maybe people don't know what it is for and miss it, maybe ... This is not a gripe at you in particular, but I have this terribly awful sinking feeling that Base is being slowly pushed back into a state where it will be soon of no use to anyone. UI changes are one of the first most visible signs of such a slide IMHO. First, we remove the buttons, then people think, oh, you can't do db stuff from the spreadsheet or wordprocessor, so just forget the db thing, etc, etc, well you get my drift. I apologise if I appear paranoid here, and like I say, this is not directed at you in person, but this is a real fear that I have, and so far my fears have not been allayed. I understand your fears - but this is the problem having a software that intends to solve the one size fits all issue (which won't be solved ever). Thus, its crucial to make wise decisions for the LibreOffice core product - target users and data can help here. Concerning the recent change - I'm also a bit worried, since nobody discussed it in advance (at least I wasn't aware of). That's the crux for people like you Samual, really wanting to improve things ... but having individual voices asking for changes. So, for such stuff, I propose to ping the mailing list libreoffice-ux-advice [1] that has been set up by Thorsten. Maybe we can sort this out together. Cheers, Christoph [1] http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Removes data sources button from standard toolbars in Calc and Writer
Hi Samuel, thanks for your kind reply ... Am Sonntag, den 12.06.2011, 08:38 -0700 schrieb Samuel Cantrell: [...] I was thinking about some of the things you mentioned...I believe that Mozilla had some kind of testing where they (with the user's permission) took data on which buttons were used the most often in the various Firefox 4 testing builds. Maybe we could do something similar with LibreOffice, to find out what buttons are used the most and when? (The UX team might find that kind of data interesting.) In OpenOffice.org, we had such a system called OpenOffice.org Improvement Program (a.k.a. User Feedback Program, a.k.a. Usage Tracking). You may have a look at (implementation) details [1], or results [2]. I extensively used this data for the printer dialog redesign [3]. The system was mainly visible on Windows platforms, since most Linux distributions disabled it. And as you already mentioned - although it was a bit buggy (some actions weren't tracked), or difficult to use (required detective work), and data access limited (only raw data available to the community), the overall system was (and is) still a great resource and helpful for making good UI decisions. The system consisted of both a sender (the code in OpenOffice.org/ LibreOffice) and a receiver (the server side to collect, transform and store the data). Unfortunately, the server side is available within Oracle only - so we don't have any access to recent and more complex data. To be honest, I'm (or let's say: the Design Team are) still searching for people/developers who might be interested to help us to rebuilt this excellent information source (the major issues besides legal stuff and server resources). [1] http://wiki.services.openoffice.org/wiki/User_Experience/OpenOffice.org_User_Feedback_Program [2] http://wiki.services.openoffice.org/wiki/Tracking_results#Results_of_the_User_Feedback_Program [3] http://wiki.services.openoffice.org/wiki/Printerpullpages/Current_State_of_Printing_OOo31#Source_Data I'm sorry if I'm coming across as trying to force changes on everyone else. I was just looking for stuff to do that was within my skillset, saw that someone had mentioned this idea [...] Oh, my impression was different - more like Cool that you joined to help us! But how to make sure that this change is perceived as an improvement for the majority of users. That's something we still try to figure out - and the reason for the libo-ux-advice list. So, please keep up the good work ... we really need people who are interested in improving LibO step-by-step. I'll send a message to the UX list later today asking what they think. Hehe, I did some quick analysis with the data available... Some notes: * Items: * AcceleratorExecute = keyboard shortcut * GenericToolbarController = application menu * MenuBarManager = context menu / menu bar * The absolute numbers are not that helpful, so we have to normalize them. -- Thus, the toolbar element File Open refers to 100%. *** Comparison Writer GenericToolbarController .uno:Open 110056 (100%) *** Writer (.uno:ViewDataSourceBrowser) AcceleratorExecute 18230 (16%) GenericToolbarController 5744 (5,2%) MenuBarManager 985 (0,9%) *** Calc (.uno:ViewDataSourceBrowser) AcceleratorExecute 10691 (9,7%) GenericToolbarController 2362 (2,1%) MenuBarManager 799 (0,7%) So what can we see here? The data suggests that most people use the keyboard shortcuts instead of the menu or the toolbar items. So we might guess that the removal of the toolbar icon is okay ... But, the buttons seem to be used more often (4 ... 5 times) than the corresponding application menu items - still a lot. Sometimes this doesn't matter that much - so it would be interesting how the use of these toolbar buttons relate to all the toolbar items visible for the user. Personally, this means a fifty/fifty chance to get an improvement - if the item is removed. To me, it would make sense to have a more complete analysis concerning the UI (like [2] for Impress). My very personal view: I think the usual LibO users will benefit if the item is removed. Instead, we should try to fix the position of the data sources explorer (currently in the View menu), but there is no easy fix (in the OOo UX team, we discussed such issues lengthly ...). Did that help somehow, at least being a first step? Cheers, Christoph Samuel Cantrell On Sun, Jun 12, 2011 at 5:08 AM, Christoph Noack christ...@dogmatux.com wrote: Hi Alex, hi Samuel! Am Sonntag, den 12.06.2011, 10:22 +0200 schrieb Alexander Thurgood: The data sources explorer is still accessible from the View menu, and my patch didn't affect that. I agree that data sources are useful. I don't necessarily agree that it's necessary to have an extra button on the standard toolbar that users have
Re: [Libreoffice] [Libreoffice-ux-advise] Performance improvements for calcs' sheet actions
Hi Michael, Markus, ... :-) Am Freitag, den 10.06.2011, 10:19 +0100 schrieb Michael Meeks: Hi Christophe, On Wed, 2011-06-08 at 00:18 +0200, Christoph Noack wrote: [...] If it takes four seconds we get perhaps the worst case: for the first 1/2 second we'll not see anything - then we get 12%, then 25% then 37.5% then 50% and so on over the remaining 3.5 seconds. Personally I think that is 'smooth enough' [...] Mmmh, it may still feel old school - although I'm not representing the visual design side (I'm more experienced in usability/utility stuff). So, if there is a chance to both keep a decent performance and let it behave nice, then ... you know ;-) Thus, if we know (and its possible), we should simply avoid the progress indicator for such fast operations. Sure - so this should be quite easy; after our first half-second, we can judge the percentage completeness, if it is 50% we can not show it [ though we would need to un-conditionally if it is not complete another second later I guess ]. Since a few days passed, I was thinking whether the initial stated 500ms do really fit ... but this is something that might be easily tweaked in the code, or? [...] By the way, another question. One of the things that might (visually) drive people nuts is the fact, that we (almost) use the whole width of the status bar to show the progress bar ... on large screens, this leads to 50cm progressbar flashing. Wow - so; it would be great to shrink that progress bar - that would simultaneously make it much faster to render; mine is perhaps 1600 pixels wide so with a gradient so: perhaps this is the key fix. Would it be possible to adapt the progress bar to be (let's say) 200px (if space permits), or smaller (if the LibO window size isn't adequate). Visually, this would be an improvement ... Yes ! :-) it is a win-win I think. That would be great! I felt free to collect some (more detailed) information in the Design Team's Whiteboards section. Please have a look ... at the moment, I omitted the wait 500ms stuff. My rationale: There is a lot (let's use Michael's usual terms) progress bar nastiness in LibreOffice, so I thought it would be great to have a common resource for that. http://wiki.documentfoundation.org/Design/Whiteboards/Progress_Indicators For those who want to dig a bit deeper into the beauty and utility of progress indicators, Thanks for the helpful input; good stuff. Markus - do you have enough to go on ? and/or are you excited :-) Markus, will that work? Please tell me what you need. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Performance improvements for calcs' sheet actions
Hi all! Let's add some more issues ... and thoughts :-) Am Dienstag, den 07.06.2011, 15:02 +0100 schrieb Michael Meeks: Hi Cor, On Mon, 2011-06-06 at 20:41 +0200, Cor Nouws wrote: So, I wonder if the UX guys don't mind us never updating a progress bar more than twice per second (say) [1] we could do this for all progress bars in one place. Would really like to have an impression how that looks like. In a world where people and software go more and more about eye-candidness .. True. Of course, there is some magic on some platforms to let the progress indicators appear continuously updated, but the most sane solution is to really provide smooth data to them. As Cor pointed out, this is for the experience part in UX ... everything else behaves 80's :-) Moreover, in some rare cases the real performance (efficiency) of the system is less important than the perceived progress - a task may take longer, but showing a good progress indicator makes it feel quicker. (There is some research data out there, but I skip it for the moment.) Oh; hmm, well - it will mean that if you are doing a fairly fast operation, you are likely to see only two frames per second of the scroll-bar, so perhaps you see only 15%, and 75% and then it disappears. And here might start the difference from what is usually proposed from an UX point-of-view. Usually it is requested to show a progress indicator (here: progress bar) if the system requires more than one second to complete the request (Gnome HIG states this a bit different, [1]). Thus, if we know (and its possible), we should simply avoid the progress indicator for such fast operations. Perhaps more interestingly, if it is a sub 500ms operation, perhaps you never see the scroll-bar at all (and no associated UI flash-bang around accommodating it) - though perhaps we do that now. True, but you also stated perhaps you never see ... so there is still the chance that the UI flash-bangs. So my question ... Is that possible (technically): * If an operation will take less than (tbd) ms to be completed, then no progress bar indication will be shown. * If an operation will take equal or more than (tbd) ms to be completed, then a progress bar will be shown. In this case, the progress bar will be drawn smoothly (pixel wise). * Note: (tbd) refers to the same value, e.g. 500. The given times should consider the system performance LibO actually runs on. @Michael: and of course we need lots of configuration options ;-))) By the way, the more I think about it ... in MS Office 2007, the progress bar behavior is a bit strange. To me (again, unable to check now) it seems that a progress bar is only shown in the status bar if some time (500ms?) already passed for a certain operation - it seems they start any kind of operation and then check if there is a need to show a progress bar. If yes, they do so and start from 0% ... (Later on, they use progress dialogs, but this is another story.) From a user-experience view, things that previously were slow - spend their time rendering pixel-by-pixel increments in the scroll-bar at high frequency now get substantially faster. Of course if something is -really- slow, then we'll still get that pixel-by-pixel look - just updated only at 2 fps. By the way, another question. One of the things that might (visually) drive people nuts is the fact, that we (almost) use the whole width of the status bar to show the progress bar ... on large screens, this leads to 50cm progressbar flashing. Would it be possible to adapt the progress bar to be (let's say) 200px (if space permits), or smaller (if the LibO window size isn't adequate). Visually, this would be an improvement ... [...] For those who want to dig a bit deeper into the beauty and utility of progress indicators, here is the Status quo (still valid) of (the different) progress indicators (2007): http://specs.openoffice.org/ui_in_general/progress/ProgressIndicators.odp Cheers, Christoph [1] http://developer.gnome.org/hig-book/2.91/feedback-response-times.html.en ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Introduce HideDisabledMenuItems style setting
Hi Christian! Sorry, it seems that I'm still a bit confused about that issue ... Am Mittwoch, den 27.04.2011, 11:13 + schrieb Christian Dywan: Am 27.04.2011 13:01:36 schrieb Christoph Noack: Just a small question ... do I get it right that the disabled menu items get hidden instead of being grayed out? Real interest: could you please explain what the rationale for the change is? As far as I know, there is currently no platform guideline that requires that (or even allows that) - but I might be wrong. Yes, disabled becomes hidden effectively. That is *current* behaviour on all systems as far as I can tell, so I'm not introducing anything new, to make that clear. Okay, then we really talk about those items in the application menu - now being hidden instead of grayed out temporarily (during runtime). I explicitly want to change this for GTK+ because it is wrong behaviour. As far as I know, OS X and KDE are the only platforms doing this (I'll ignore Maemo). I don't know the exact guideline, I didn't find clear documentation Mac OS X Human Interface Guidelines Naming Menu Items: When a menu item is unavailable—because it doesn’t apply to the selected object or to the selected object in its current state, or because nothing is selected, for example—the item should appear dimmed (gray) in the menu ... http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGMenus/XHIGMenus.html#//apple_ref/doc/uid/TP3356-TP6 KDE User Interface Guidelines Menu items should not be added or removed during runtime. Disable or enable them instead. http://developer.kde.org/documentation/standards/kde/style/menus/index.html GNOME Human Interface Guidelines 4.3.2.1. Command Items Guidelines: Do not remove command items from the menu when they are unavailable, make them insensitive instead. http://developer.gnome.org/hig-book/2.91/menus-design.html.en Microsoft User Experience Interaction Guidelines Disable menu items that don't apply to the current context, instead of removing them. Doing so makes menu bar contents stable and easier to find. http://msdn.microsoft.com/en-us/library/aa511502.aspx#presentation Is that the information you searched for? about it but for example the web page context menu on OS X does it and editor popups I saw in KDE. In this case, context menus are a different matter - they hide elements instead of removing them (or positively: only show what's available). But we have other issues within our context menus that need to be fixed (since 15 years or so *g*). That said, Lubos or anyone else, please correct me if my observation is wrong, I'll adapt the patch accordingly. [...] Regards, Christoph -- LibreOffice Design Team. Make it just work, and look great, too! http://wiki.documentfoundation.org/Design ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Introduce HideDisabledMenuItems style setting
Hi Christian, all! Just a small question ... do I get it right that the disabled menu items get hidden instead of being grayed out? Real interest: could you please explain what the rationale for the change is? As far as I know, there is currently no platform guideline that requires that (or even allows that) - but I might be wrong. Cheers, Christoph Am Donnerstag, den 21.04.2011, 13:44 + schrieb Christian Dywan: I'm introducing a setting that decides if disabled menu items should be hidden. Currently the code is broken in the sense that items are hidden if disabled on all platforms and UpdateApplicationSettings which theortically does that is a) counter-intuitive and b) not set by platforms. The patch sets the setting for KDE, KDE4 and OSX and uses it for the edit menu. Future steps are to use the setting for other menus and I think UpdateApplicationSettings should eventually be removed because it's completely mis-designed and confusing. ciao, Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Smart art like functionality
Hi Thorsten! Am Donnerstag, den 21.04.2011, 14:58 +0200 schrieb Thorsten Behrens: Christoph Noack wrote: OOo wiki page IntelligentGroup (by RedOffice) http://wiki.services.openoffice.org/wiki/IntelligentGroup A specification draft (quite complete if we want to stick with the today's GUI ... also available from the page above) http://wiki.services.openoffice.org/wiki/File:IntelligentGroupSpec.odt Um - of course I'm not without bias here - but the intelligent group work is * only avaible in Impress * does not help at all for importing ooxml * apparently abandoned ... ;) Hehe, I tried to answer Kami's question with regard to any related documentation, design draft, goal etc. Whether it is abandoned or not :-) So to say, I'm less biased and even code-neutral ... Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-design] Git Artwork guide
Hi Björn, this is just amazing - thanks! After giving it an initial try a few months ago, I never spend more time to explore Git a bit further ... And also a big thank you to Thorsten who already added his great icon workflow :-) Am Mittwoch, den 20.04.2011, 11:12 +0200 schrieb Bjoern Michaelsen: [...] I created a short tutorial for designers on how to get setup to contribute artwork directly to the project at without a complete build: http://wiki.documentfoundation.org/Design/GitArtworkGuide @Designers: Feel free to move it, beautify it and most of all: link to it. Since, we already have a Tools page I've started at OOo, so ... * linked to the GitArtworkGuide from there and also added a link to the artwork repository (cgit) * moved Thorsten's description (icon workflow) to this page * linked to the new items from the LibreOffice Initial Icons page http://wiki.documentfoundation.org/Design/User_Experience/Tools#Support.2C_Documentation_and_Development @Developers: Feel free to improve the guide, if I missed out some pits that should be informed about. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Smart art like functionality
Hi Kami, all! Am Mittwoch, den 20.04.2011, 17:14 +0200 schrieb KAMI911 KAMI911: Hi Fellowship of Programmers, ??? :-) We are very excited about the possibilities of LibreOffice, so we decided to try to rewrite Diagram extension [1] in C as a separated module. Are there any ongoing development to create SmartArt related thing? Maybe the best would be to as like the Chart2 module. But we need help for the first steps. How can we start it? Or are there any related documentation, design draft, goal etc? About one month ago, we had somebody approaching the Design list concerning this topic. To make a long(er) story short, we collected some material that has been created for OOo. OOo wiki page IntelligentGroup (by RedOffice) http://wiki.services.openoffice.org/wiki/IntelligentGroup A specification draft (quite complete if we want to stick with the today's GUI ... also available from the page above) http://wiki.services.openoffice.org/wiki/File:IntelligentGroupSpec.odt The OOoCon 2009 presentation for IntelligentGroup http://conference.services.openoffice.org/index.php/ooocon/2009/paper/view/34/91 Providing a link to the source code at: http://svn.services.openoffice.org/ooo/cws/impressintelligentgroup01 Announcement by the developers on the OOo dev list: http://openoffice.org/projects/www/lists/dev/archive/2009-03/message/233 The Microsoft Office SmartArt description: http://en.wikipedia.org/wiki/Microsoft_Office_2007#SmartArt Here is the SmartArt thread starter on the Design ML: http://www.mail-archive.com/design@libreoffice.org/msg01317.html Thanks for Andreas Mantke who helped to collect that stuff. Hope this helps ... Cheers, Christoph Best regards, KAMI [1] http://wiki.services.openoffice.org/wiki/Diagram_Extension ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#31251 - Improve default page layout
Hi Sébastien, all! Am Dienstag, den 19.04.2011, 08:51 +0200 schrieb Sébastien Le Ray: [... previous mails and topics ...] We've a 4 sided shadow, should I port it Writer as is or are their request of improvment? Should I let the color configuration option for shadow color and use the value under draw or just drop it? Not an easy answer, so a step-by-step approach ... easy to tough questions: [...] They used a simple bimap. Their approach is more or less the same as the first implementation I did (when no color configuration was possible), except they just use one bitmap that they split at predefined positions instead of having one bitmap per side/corner. Ah, okay. Thanks for the explanation! * The shadow color configuration might be dropped -- At least if we can find a shadow that works well on most backgrounds (e.g. finding an appropriate color, or calculating the shadow based on the application background color - preferred). That would save users a bit effort and help the translation / documentation teams as well. I guess the current impress shadow should be nice on any background since there is an alpha channel and no area has a full opacity… From my point-of-view, that would be fine. * Anyway, it would be good to have a bit more control how the shadow was created, because we might need matching shadows for other objects (e.g. Notes, Panes, ...) -- I think, the specification we've started is a good basis, so do you think we can continue with that (see my note below, please). I just need to know what graphics we can use to realize good effects at the document edges (see my last mail). I can't find the mail about the document corners… I attached you the bitmap used in impress to draw the shadow. Ah, perfect! That makes clear how they solved the issue in the mail I've mentioned (sent on the Design list) - it was about how they get the naturally shadowed edges: http://listarchives.libreoffice.org/www/design/msg01571.html * A more attractive document background is still desirable -- can we go with a gradient in the next step? I think we'll have to test how gradients can be used to get a nice background. Keeping in mind that current gradient implementation focuses on performances rather than on quality… Ah, you mean the internal one that is also used for drawing objects. Personally, I don't know if the implementation is efficient - I just noticed some drawing bugs in the past. As always - thanks in advance :-) I'll try to quickly implement and push impress shadow to sw so you can see the result throught the nightlies Cool! And since we now have the shadow picture, we might even tweak it without that much issues. One last thing - I apologize for the quality of some of my mails. I don't know why, but I tend to reply to your posts at the end of my (LibO) day ... Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#31251 - Improve default page layout
Hi Sébastien, Thomas, all! Am Samstag, den 16.04.2011, 14:41 +0200 schrieb Sébastien Le Ray: Le Sat, 16 Apr 2011 13:31:58 +, Thomas Arnhold tho...@arnhold.org a écrit : I like your patches for the new smooth shadow. I looked around the other LibO apps like Impress or Draw. They have this shadow already, but it's not as width as in Writer and it's on all sides. Maybe we should do it in Writer as in Draw and Impress. Looks better I think. Here is what I mean: http://infoo.org/shot-20110323-062300.png I was planning to go on on draw impress this week but it seems someone already did the job… I don't know where this shadow comes from, maybe from the OOo integration… I can't see any git log message related to it Yes, this is very likely ... that was something being planned since several months (based on UX team discussions), but I didn't knew that the Impress team finally implemented that. @ Thomas: Do you have some screenshots how it looks like? I plan to have a look at a recent daily build, so I hope to have a look at it. @ Sébastien: Would it be possible that you'll have a look how it is implemented. Any chance that we - as Thomas mentioned - get this streamlined throughout the applications? If yes, then I plan to validate the current specification draft and to update it ... so we can go on. For those who are interested: http://wiki.documentfoundation.org/Design/Development/DocumentBackground Thanks a lot! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#31251 - Improve default page layout
Hi Sébastien! Thanks for the ultra-fast reply :-) Am Samstag, den 16.04.2011, 15:01 +0200 schrieb Sébastien Le Ray: Le Sat, 16 Apr 2011 14:58:46 +0200, [...] @ Sébastien: Would it be possible that you'll have a look how it is implemented. Any chance that we - as Thomas mentioned - get this streamlined throughout the applications? Yes I'm gonna check this out… But If nothing more has changed, the way page redraw is handled in writer is much more different than the way it is in draw… What we do not know is if OOo did the work for writer too and we've overriden it or if it hasn't been done… I don't think so ... last time we discussed that at OOo, the shadow improvements were related to Renaissance. And the Renaissance project explicitly addressed Impress (and Draw, since it is based on the very same code base). So we may have some further benefit with Writer :-) I'll have a second look whether I find any OOo UX specifications ... Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-design] About the Navigator
Hi Ricardo, all! Ricardo, thanks for summarizing the proposals. Some of them have real EasyHack quality, I think. I added some behavioral description to 36308 (the first one). Since I don't know better (as well), I also forward your mail to the developer list. Maybe they can suggest how to handle that - e.g. additionally adding it to the EasyHacks list in the wiki. Dear developers, the proposals address Navigator functionality ... Am Samstag, den 16.04.2011, 22:33 +0200 schrieb RGB ES: 2011/4/13 RGB ES rgb.m...@gmail.com: I made a quick draft summarizing the discussion on this thread: https://sites.google.com/site/rgbmldcwriterideas/home/navigator/navigator-en.odt?attredirects=0d=1 I reduced everything to three proposals: - Change the tree view behaviour - Reorganizing the way on which the info is presented (i.e. Christoph mock-up) - My crazy idea about drag-n-drop cross-references About adding this to the list of easy hacks... well, I'm not sure *where* and, more important, I have no idea of the needed skills for each proposal. Not knowing which is the best place on the easy hacks page to put these ideas, I filled three separated feature requests on Bugzilla: [UI]Change behaviour for tree view on Writer's Navigator https://bugs.freedesktop.org/show_bug.cgi?id=36308 [UI]Better interface for Navigator's tree-view https://bugs.freedesktop.org/show_bug.cgi?id=36309 [EDITING]Insert cross-reference drag-n-drop mode for navigator https://bugs.freedesktop.org/show_bug.cgi?id=36310 feel free to comment (and implement! ;) ) them. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] conditional formatting with an unlimited number of rules
Hi Bob, finally a bit time to reply to your great mail :-) Am Dienstag, den 12.04.2011, 00:54 +0200 schrieb Robert Dargaud: Hello Christoph, Le 11/04/11 23:42, Christoph Noack a écrit : [...] Hehe ... then we should talk. To be honest, please tell me if you want to give this another try - or if you want to have a look at another topic as well. Yes, I want continue on this subject because it seems to me that it's a good way to learn LibO code. Cool! There is so much to learn ;-) [...] I'm currently thinking about whether something like the Custom Document Properties [1] might be a next step - the UI design pattern might fit here as well. Mmh ... Oh ! Yes !!! It seem perfectly adapted, I have a look to code and start to hack tomorow Amazing! Just tell if you have any questions related to the UI behavior or user's needs ... I think (but I'm not a developer) that the main issue will be to build a table with entries similar to the current ones (having several controls stacked in a container that represents a list item). A simple table like the one for the custom document properties might not work ... to many information / controls. Or at least I don't know if there is a solution that will work well nevertheless. At least, we may get rid of the Checkbox, and place the New Style ... below the table (because it is a rather generic control). And (dreaming) one day, we'll be able to provide something like LivePreview (or Apply behavior) for such dialogs :-) And I will debug refresh ... who is not really perfect ! like you can see on screen shot below. http://archives.bobiciel.com/libo/custom_properties/custom_document_properties_LibO_ubuntu.jpg http://archives.bobiciel.com/libo/custom_properties/custom_document_properties_OOo_Mac.jpg Ouch! Doesn't look that nice ... that's true. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] conditional formatting with an unlimited number of rules
Hi all! Am Montag, den 11.04.2011, 01:09 +0200 schrieb Robert Dargaud: Hi Katarina Christoph ( All), I have improved code like you suggest. Cool, thanks! :-) [...] And - of course - I also have some ideas how to really improve the dialog and bring it to the 2010s :-) But this may require a bit more work for all of us :-) Me too, I've some ideas : It should be between the simplicity of Apple Number and the gaz factory of MSO 2010 ;-) Hehe ... then we should talk. To be honest, please tell me if you want to give this another try - or if you want to have a look at another topic as well. But in first time, I wanted to propose a solution that does not disrupt the current user interface. And your current solution seems to fit perfectly with regard to this goal. It's great to hear that you care about the current UI constraints - and how to provide a good solution nevertheless. I'm currently thinking about whether something like the Custom Document Properties [1] might be a next step - the UI design pattern might fit here as well. Mmh ... Cheers, Christoph [1] http://specs.openoffice.org/appwide/fileIO/Custom_Document_Properties.odt ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Samuel, hi Ivan, all! Am Montag, den 04.04.2011, 22:57 +0100 schrieb Samuel Atkins: On 04/04/2011 11:14 AM, Ivan M. wrote: [...] I do have one question though: would the submitted form actually submit a bug report in Bugzilla, or would it get sent to someone for moderation/confirmation? [...] I think the plan was to have it submit directly to bugzilla, but it may well be beneficial to have some sort of moderation. I don't know whether this had been discussed already - but I think Bugzilla itself may be the tool to do the moderation (unconfirmed -- confirmed). But then it'll be helpful to identify where the bug came from ... maybe adding a keyword like BugFromSimpleBugForm that enables filtering? E.g. for letting QA focus on such issues, or even doing some statistics (e.g. how many of these bugs turned into duplicates). Last year, I've attended a very nice research talk that dealed with Mozilla bug reports and their reporters. Just by 2 cents. Thank you both for working on that! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Samuel, great to hear that you continue this project ... Am Montag, den 21.03.2011, 21:53 + schrieb Samuel Atkins: Hello all, I'd like to pick-up this project, as it looks like something I could accomplish! [...] So this is largely an introduction. So, hello! And of course, if anyone has any input, feel free. Just a few questions at the beginning: * Is that bug filing form intended to help less experienced users? (Within this mail, I'll assume that). * Is the formatting of the page final, or will it be embedded in another web page? At the moment, there are some minor issues and some things that look a bit illogical to me (but this may only be me). So please bear with me when I simply state some of these issues: * When choosing the options, users might miss the information whether they are finished or not. So my proposal would be to state a text / placeholder like Further information required. and add visual clues (spacing, subtle headings, or ...) between the different questions. * The large heading Before you file ... seems to be a heading for the whole page - I'm sure it is not. The whole page is about the bug report (= the heading) and some hints to consider before filing any issue (proposal: a separate box at the top). There, please include the If you are having more than one problem ... * The whole text seems a bit too technical (assumption: less technical users). There is #libreoffice IRC, crash, ODF (on the wiki pages), bug, ... * The combination of some entries seems a bit strange, e.g.: * There is a problem with the website + Crashes the program * LibreOffice crashes + Does it crash ... load or save ... document? YES + Do you need to load a document to execute those steps NO. * Some helpful hints might be less helpful for users, e.g.: * If possible, please search the bug reports before ... -- If the users are less experienced, how and where to do that? If I remember correctly, Gnome let the user enter some terms and then searches within such kind of bug filing form. * Are you sure ... fonts installed. Bear in mind ... may list fonts that are not installed. -- How should the user identify what kind of fonts are installed (still, I assume less experienced users). * document ... then attach it -- where? (Maybe it's not yet implemented, but I didn't see the nice placeholders you used elsewhere). * Formatting stuff: * The Description fields are very small - maybe the problems are small as well, but I think it is helpful to increase the field size a bit. (On my computer, the current size is approx 4x2 cm) * The radio buttons are itself a list, so we might skip the additional bullets. * It would be just great if the For help on this, see here could just open an additional section below the current section. That would save the users to jump back an forth with the newly opened browser windows. I hope this list doesn't look discouraging - quite the contrary. To me, it's a real please that somebody picked up this topic. So if you need more detailed proposals / an in-depth review, then please let me know (or just ping the Design Team). I'll wait for your request until you think it's ready ... Again, thanks for working on that! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc Standard Filter behaviour
Hi Tibby, hi Kohei! Just a (maybe) silly question ... below. Am Mittwoch, den 09.03.2011, 10:36 -0500 schrieb Kohei Yoshida: Hello Tibby, First off, welcome to this project! And I'm glad to see you taking on fixing this one. We have lots of silly UI issues like this, and it's good to have more hackers joining in to fix them. Same from my side :-) On Tue, 2011-03-08 at 19:24 +, Tibby Lickle wrote: [...] Now, to me the best solution is to *not* show any auto completion value in the text box itself, but to show a little popup box with possible auto-completion options to choose from, while leaving the typed value in the box intact. But this would require a little more coding and could potentially become more difficult to figure out. So I think the above solution would be good enough, and much better than what we have now. Is it really helpful to use auto-completion in this box (in this special case)? As far as I can understand, users enter values because they there is no selection available in the drop-down box. Or is the hard part (the coding you mentioned) disabling / removing auto-completion? However, accessibility is kept, since both Cursor Up/Down and Alt +Cursor Down work as expected to quickly select items. Don't know whether this helped ... Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] More general stuff (was: Re: [libreoffice-design] Re: [PUSHED] fdo#31251 - Improve default page layout)
Hi Michael, Sébastien, all! First, thanks Sébastien for your effort - this statement is most important to me at the moment :-) The second most important statement is, that I share some of Michael's concerns. So please let me shed some light on the issue. And for the developers, this might also be helpful ... and grab a coffee (or something equally nice). Am Dienstag, den 08.03.2011, 12:05 + schrieb Michael Meeks: Hi Sebastien, On Tue, 2011-03-08 at 09:09 +0100, Sébastien Le Ray wrote: this simple shadow patch has generated a long discussion on Libreoffice-design. Some people don't like the color, some people don't like the amount of blur, some people want no shadow at all, some people want a 4 borders shadow. So here is a second patchset that tries to address the first three critics : So - firstly, this -sounds- like an interaction disaster :-) I hope it is not of course, but it looks like this: We finally get a competant, enthusiastic, motivated developer - actually fixing our horrible user interface problems: and he does some great improvement - and our design guys apparently emit a long stream of complaining left and right ! That, if true, is hard to excuse. May I rephrase this a bit? We, as well, have new enthusiastic and motivated people on the design list. And some of those guys still need to gain some experience - otherwise they do the best they can: they offer their / other's personal opinion on issues that pop up: I like red. Joe never wanted it so. This looks bad. I always use this. But personal opinions are, well, personal opinions. Usually this personal statements don't match with usability requirements or the overall visual language we require to serve that many users. Since the outcome of the Design Team is usually information (this will work) wrapped in words (and not code), it is very hard to distinguish who might be right. If person A says Left and person B says Right, whom to believe? This talk happens ... it happened in the OOo UX team, it happens in all FLOSS design and usability lists. And the entry barrier to such discussions is quite low ;-) So this is something we (Design Team itself) has to deal with. Thus, the more experienced team members try to explain why this or that won't work by giving some rationale - this might appear as a noisy discussion and takes time. In this case, we aim for guidance for less experienced people, not for the quickest decisions (at the moment). But also the long-term members discuss proposals (as we did for the icons being now pretty mature). This is like patching code - it requires some iterations to get a reasonable state. And similar to code peer-reviews, we usually decide when to release something to (for example) you. For the current issue, there has been quite some discussion. So Nik offered to do a mockup to support the patching/improving before doing the real implementation ... this was the idea. Sébastien was (simply) a bit faster with a first implementation. [...] I think we need to remember that the perfect is the sworn enemy of the good - so lets get good across the code, before we get perfect. In general, I would say, please ping us in advance - if somehow possible. As you might get comfortable with the code, it also helps us to have some time to get settled with the issue. There is no magic stuff like Instant Usability or Ready-to-serve Design. And if you want to work on the code before getting in touch with us, please add a bit patience to the request ;-) Personally, I'd like to both look at Sébastiens work, and on Nik's work once being reade. [...] Personally, I would have preferred you to move on to some other fun / high-impact win, rather than getting bogged down in random details here ;-) +1 So here a short takeaway: * Please ping us in any case if you need something * Have also in mind that some of our members are new and also need some time to get settled -- expect personal likings, relax and wait for a mature outcome * If you require a decision more quickly, or if you're unsure about the current state, then please feel free to bother us ... * Over the time we'll get to know each other ... and you'll know whom to trust ;-) Oh, and this may be an excellent chance to ask you something - we are currently in a phase of defining what we (and others, like you) need to work with us efficiently. Thus, would it help to have a page How to request stuff from the Design Team? in the wiki? There, we could describe how things should work, what to expect, ... Okay, I hope this helped a bit to clarify some things ... it's just two mailing lists, but from the deliverables point-of-view, it is vastly different. Cheers, Christoph PS: Still, if you want to have a look how we look like ... http://wiki.documentfoundation.org/Design/Team ___ LibreOffice mailing list
Re: [Libreoffice] [PUSHED] fdo#31251 - Improve default page layout
Hi Sébastien, thanks for your mail ... so let's continue the small discussion we had offline. Am Freitag, den 04.03.2011, 08:42 +0100 schrieb Sébastien Le Ray: Le Thu, 03 Mar 2011 21:35:11 +0100, Christoph Noack christ...@dogmatux.com a écrit : Am Donnerstag, den 03.03.2011, 14:16 +0100 schrieb Sébastien Le Ray: Le Thu, 03 Mar 2011 11:59:19 +, Michael Meeks michael.me...@novell.com a écrit : [...] Personally, I've already spend over one year with the Notes project being the UX representative, so I'd like to work with you on that - if you like :-) I'll be pleased to :) It'd be nice to have a UI tasks on libreoffice wiki presenting all tasks that are ready on a Design point of view but that have not yet been implemented. There is a lot of stuff on the Note2 wiki page, could you give priorities on various items? Mmh, hard to say ... because it might also depend on the effort that has to be spend on your side. But let's give that a try - it helps me to differentiate between issues, visual improvements, and feature enhancements. ISSUES (Medium) Although invisible, this would be a great fix: http://openoffice.org/bugzilla/show_bug.cgi?id=85844 (High) The small triangle (note anchor) still looks a bit awkward. Originally, I tried to come up with a proposal that suits different kinds of anchors (see also below). Here is a screenshot for the I-shaped anchor (in the center of the graphic) that should replace the current triangle. http://wiki.services.openoffice.org/wiki/Notes2_Design_NoteAnchor#Proposal_.22Boxes_.28Note_Anchor_Area.29.22 VISUAL IMPROVEMENTS (Low) The implementation does not always follow the initial design - for several reasons. If you look at the screenshots, you may spot some differences (e.g. dashed line vs. dashed line above normal stroke line, or 2px width between Notes Sidepane and document vs. requested 1px width). Small things, but they improve the overall impression. (Medium) Something between issue and visual improvement is to get rid of the plain background when notes are edited. Originally, we wanted to keep the gradient for all states. (Medium) Since you've already invested some time into the nice shadow thing, the understandability of focus would be greatly enhanced by ... http://wiki.services.openoffice.org/wiki/Notes2_Design_Visualization_of_Focus#Proposal_.22Increased_Shadow.22 FEATURE ENHANCEMENTS (High) One of the most important requests for Writer is still to have proper Notes printing. On the first glance, it might be invisible to the users, but when printed - it will shine :-) http://wiki.services.openoffice.org/wiki/Notes2_Design_Printing (Medium) Today, we only support note anchors representing one character. We miss the functionality to markup a word, or even a whole sentence - the note anchor areas. Screenshot below - but there is also some detailed description on the behavior of such a feature. http://wiki.services.openoffice.org/wiki/Notes2_Design_NoteAnchor#Proposal_.22Boxes_.28Note_Anchor_Area.29.22 (Medium) Another nice thing would be a Notes ruler control that enables the user to show/hide the Notes: http://wiki.services.openoffice.org/wiki/Notes2_Design_NotesSidePane#Proposal_.22Notes_Ruler_Control.22 (Medium) My personal favorite - which seems unique among the office suites - is still the notes placeholder. This is a decent placeholder that enables to just start typing the notes text after having clicked on it (anchor would be placed at current document text position, the placeholder has the same size as a freshly created note). Here is a preview: http://wiki.services.openoffice.org/w/images/8/81/Notes2_2007-09-08_GeneralMockups_View.png And so on, and so on. Does that help somehow? [...] http://wiki.documentfoundation.org/Design Subscribed yesterday :-) It seems that you've been busy with more marketting stuff that UI design lately to cover the launch of LO, FOSDEM and funraising Cool, great to have you here ... aehm ... there. And you are right with your busy assumptions. Especially the funraising seems to be the hardest part in this project ;-) Waiting for you priorities mockups on notes work :-) Hehe, thanks a lot! Great to hear that ... Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] New feature: print current page
Hi Kendy, Tobias, Cor, all! Am Mittwoch, den 23.02.2011, 10:54 +0100 schrieb Jan Holesovsky: [...] Indeed, that would be great. I noticed another issue that seems to be different with regard to the original specification. And, there is a serious usability/utility issue since the dialog doesn't save printer / printing options in certain cases. So if there is a helpful (developer) hand, then I'd like to resolve this ... Anybody? :-) Well, I really would like to help. But as I said, I'm new here and have absolutely no experience in developing LibreOffice/OpenOffice. Although if this is kind of easy work, I could give it a try. [... code pointers and explanations ...] I'll add it to Easy hacks too, when you start working on it, please mark it in the wiki page that you are working on it: http://wiki.documentfoundation.org/Development/Easy_Hacks#Print_current_page Kendy, I had a look at the old functionality and felt free to add some more information on that page - including some links to the printerpullpages specification I've wrote for OOo. I hope that's okay, because it adds even more info on that page. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Daniel, also from my side - thanks for having a look at the bug filing and the results created so far. It's great to see somebody picking up stuff like that to improve some hidden sides of LibreOffice ... If anybody wants to continue with this topic, then please CC the Design Team or me, so that we can help here (usability, text descriptions, ... Michael already provided a great proposal). Again, thanks for you work! Cheers, Christoph Am Sonntag, den 27.02.2011, 21:55 -0500 schrieb Daniel Neel: Alrighty, I've attached the current progress to this message and will be updating the wiki shortly. Thanks again everyone for your time. On Fri, Feb 25, 2011 at 9:37 AM, Jan Holesovsky ke...@suse.cz wrote: Hi Daniel, On 2011-02-24 at 19:37 -0500, Daniel Neel wrote: I think this project is moving a bit beyond what I currently have skill and time to complete with quality. I think it would be best for me to pass the current work on to someone else. Sorry to hear that :-( You are doing great from my point of view, but of course, cannot force you ;-) Would the best course of action be to update the EasyHacks page with a notice of the current progress on the hack, an attachment of the file, and maybe a link to this mailing list conversation? I look forward to helping out LO in other ways soon. Yes please - the best would be to send your current work to this mailing list (as a mail attachment), and add the description + link to the mail with the attachment in the mail archive (http://lists.freedesktop.org/archives/libreoffice/) + link to the entire conversation to the wiki. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Tools - Media Player
Hi Fernand, all! Am Freitag, den 25.02.2011, 16:01 +0100 schrieb Fernand Vanrie: Thomas , No we are not placing video in odt, files, but our editors (while there are working in writer), needs to see some video content as a source for there work. Wow, that seems to be a very special case - so from my side, if the menu item can be added manually (afterwards), then it should be fine for most of the users. Of course, this might add some burden on your and your editors, but most of the other users do have some benefit ... maybe this is some kind of compensation? ;-) But we would like to add some video content to our Writerfiles and then transfer them to Epup or interactive PDF's As far as I understand, that's still possible. By the way, if I can help here ... please let me know. The only downside is, that I'm still not that responsive as I would like to be :-) In such cases like Media Player use (especially in the not too far future), it would be nice to set up the usage data collection for LibreOffice. Then we might track the use for our product, since the OOo data gets old quickly ... Cheers, Christoph On 02/25/2011 12:07 PM, Fernand Vanrie wrote: Please consider: We are living and working in a Multi Media world: Not only who is working with Impress needs a media player, all content can have mixed content and LO must be the one stop place to handle all multi media stuff. I partially reverted the changes for writer. The background calls are there again, so anybody who needs Media Player could add this by customizing the menu. And I've enabled Media Player for web by default as this make really sense. Fernand, only for my personal interest: are you using videos in odt files? Maybe I'm not knowing what's possible with this ;) Thomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Tools - Media Player
Hi Thomas, Michael, all! Thanks for the great discussion ... let me add a few thoughts :-) Am Sonntag, den 13.02.2011, 19:09 +0100 schrieb Thomas Arnhold: Christoph thanks for the discussion link and the specs! You're welcome. I'd love to play a more proactive role at the moment, but referring to older discussions is what I can do at the moment ;-) On 02/12/2011 10:01 PM, Michael Meeks wrote: On Fri, 2011-02-11 at 23:08 +0100, Christoph Noack wrote: what the heck do we do with Tools - Media Player? Do we need this within an office suite? Is anyone using this?! :-) My suspicion is that ~no-one is using it. I think the same. If I add an video to a presentation I know what file I want to add. And if I want a preview of a specific file this should be done by the filepicker. Short: I share this view ... Long: But, some of the tracked usage seems to say some (strange) uses, maybe tries, maybe clicks on the wrong menu item, but at least some uses (see the end of the mail). Personally, I think we don't loose that much by removing the entry from the menu. Instead, we gain a more clean menu layout. Thomas, I'm not aware of that many file pickers being able to preview videos (given our platform support). Sometimes the Media Player might indeed be handy, e.g. to preview videos that got random names (e.g. from a camera). And, it seems that using the Media Player, previewing the video files seems much faster than prior embedding to the document (subjective, of course). However, we might rely on the operating system in such cases ... any further thoughts? [... Use Case descriptions - thanks to Michael ...] So - I think b) is fairly bogus (or the gallery addition code needs some real work), a) is a real use-case; it seems we throw up the media player for preview sounds in the shipped gallery. Oh, the gallery needs much love in any case. OpenClipart support - to name only one ... :-) [...] I tested to create a new gallery. There is some kind of lack of user experience: Open the gallery, then New theme, tab Files and then you have to click Find files at first to scan a directory for media contents. When this is done all media files get added to the list below and you could click Add or Add all to add these files to the gallery. Paradoxically, if you forget to click Find files and directly go to Add this is also possible, but with a very limited list of supported file formats (only images). That's some kind of strange. I've added ogg and mpg files and some more formats into the gallery. Works fine. Only lack is the list of supported formats. I manually added a flv-file with Insert - Movie and Sound (thats the player). But you have to choose All files. Within the gallery there is no such option. With the consequence that I can't add flv files to it, despite the fact that the player plays it ;) Wow, thanks for the detailed description. I only checked the former one - same for me. With Insert you have two possible options to add media content to the document: Insert - Movie and Sound or Insert - Object - Video/Sound. I think the second is deprecated as it doesn't really work. The gallery does add sounds and videos like Movie and Sound. So - IMHO the player-let is useful, but I'd be amazed if people really used it in anger; it is rather lame. Removing it from the menus in everything but impress might make some sense (?) Yeah for impress it is very useful. But why remove the possibility to add videos and other media to the files. I think in the background in it's the same, isn't it?! So the question is: - remove Tools - Media Player - remove Insert - Objects - Sound and Insert - Objects - Video Fine from my point-of-view (as Michael suggested, keep Media Player for Impress?). But since those objects are supported in all applications, please keep View - Toolbars - Media Playback. Cheers, Christoph === Usage Data === Data (end of 2009) ... the use of the menu bar item for opening / closing the media player (.uno:AVMediaPlayer MenuBarManager) * Writer: 638 * Calc: 152 * Impress: 594 * Draw: 77 * All Applications: 2063 Of course, these are only relative values - so here is the comparison to the Gallery item in the same menu - All Applications: 7919 Looks strange, doesn't it? Especially since Writer seems to outperform Impress. (???) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] New feature: print current page
Hi Cor, hi Tobias! Am Freitag, den 11.02.2011, 11:59 +0100 schrieb Cor Nouws: Hi Tobias, Tobias Ollmann wrote (11-02-11 12:28) I'm rather new here, so I don't know if something similar has already been posted. But I'm missing a very important feature in the printing dialog, namly an option to print the current page only. The old behaviour in OOo was - select option Pages, that default to the current page. WHich is what you want. True. Funnily, that is what I've originally wrote: Group Range and copies: Slightly improved layout which is based on the original printing dialog, since we have to respect our existing user base. [1] Seems that the original behavior hasn't been preserved :-\ With the new Printer Dialog, you can select Pages, but nor does it show the current page, nor does it get the focus, IMO two usability bugs. Correct. Concerning the latter, I somehow remember that this was in discussion and I have been overruled. Are there plans to implement something like that? Not that I am aware of. But improving the behaviour in the current dialog would do too, IMO. Indeed, that would be great. I noticed another issue that seems to be different with regard to the original specification. And, there is a serious usability/utility issue since the dialog doesn't save printer / printing options in certain cases. So if there is a helpful (developer) hand, then I'd like to resolve this ... Anybody? :-) Cheers, Christoph [1] http://wiki.services.openoffice.org/wiki/Printerpullpages ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Design Team Kick-Off Step 2: Current Status of Work and Collaboration
Hi all, this mail announces the second step of our official Design Team Kick-Off. It is about what we've done so far, and how we did it - thus, it aims to get everybody on track who is interested to join, or to collaborate. Current Status of Work and Collaboration: http://wiki.documentfoundation.org/Design/Kick-Off/CurrentWorkStatus I've CCed the other teams, since they might be interested in those topics as well ... Background: A few days ago, we've agreed on how to set up our Design Team, and we've invited other parties to join - people having interest in user experience, visual identity design, accessibility, and user support and training. Together, we'll aim for Make it just work, and look great, too! Design Team Kick-Off Page: http://wiki.documentfoundation.org/Design/Kick-Off Cheers, Christoph PS: Thanks to all who helped to fill / improve the content of the page. And to everyone else, who continued to work on other topics :-) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [UX] Rename Default Formatting -- Clear Direct Formatting
Hi Octavio, thanks for the great explanation - and also Cor for adding his support concerning the change as well. Am Freitag, den 21.01.2011, 20:49 -0800 schrieb Octavio Alvarez: christ...@dogmatux.com wrote: [..] Well, this is not true in LibreOffice anymore. This got implemented in ooo-build almost one year ago and ported to LibreOffice. See initial discussion at http://lists.freedesktop.org/archives/ooo-build/2010-February/000540.html and applied patches at http://web.archiveorange.com/archive/v/Ct2xycq5ewxra2Ornv8S Oh, good to know - to be honest, I partly relied on the help system. And in a recent LibreOffice build, it still states and formatting by character styles, see: http://picasaweb.google.com/lh/photo/MAUtH-sKeCLVDY4rSR4UWw?feat=directlink The terminology Default is used throughout the office suite. For example, the buttons Default resets all manual changes of an derived style (Stylist). Didn't find it. I see Reset and Standard. Is it any of those? Grrr, sorry - you are right. I've referred to Standard (Funnily, I used the German version stating Standard and translated to Default ... a never make assumptions case *g*) And direct might also be unknown to those users who are unsure what default formatting is. *Exactly*, because this change is NOT for those that don't use styles. For them, it is a menu item that might as well not be there. This is for those of us who *know* how to use styles. There is no loss there. For us, we know the difference between formatting that is applied by the style and formatting that works as an override. We call it hard formatting or direct formatting. What I'm a bit unsure about is, whether the change should support the people who know, or if it should take care that people get to know - just a generic comment. [...] The string length will make the menu wider, which gets an issue when the English text gets translated into foreign languages. Especially since we do have many sub-menus within this menu. Same applies to Clear All Formatting you are planning to change. Of course, sorry about that. :-/ I'll need help here to make the change as friendly as possible to others. I CC Sophie to ask her how to check that ... Sophie, the subject states the menu item change which may become rather long when translated, and thus, a usability issue for the use of the Format menu. What do you think? [...] By the way, it would be great to know some more information where this request came from [...] See the links above for the Default Formatting behavioral change. I can gladly go further if you request it, but it was to improve functionality. Oh, thanks, the explanation was already quite helpful! There are two opposite-pulling forces as shown by bugs i#47893 and i#85464 and each time this gets discussed, there are mixed opinions. Everybody think differently about this. The proposed rename clarifies what the new behavior does *exactly* as of today, so that any change follows a common criteria. Links to the referred bugs: http://qa.openoffice.org/issues/show_bug.cgi?id=85464 http://qa.openoffice.org/issues/show_bug.cgi?id=47893 Thanks! This of course doesn't mean that a Reset paragraph direct + all character shouldn't exist. It simply needs to be clearly differentiated, maybe its own menu entry. True, at the beginning, I worried more about the name change - removing some of the consistency of the suite. Due to the supportive statement by Cor, I'd like you to go ahead. But, our discussion changed my impression a bit - I'm currently thinking about an even less correct change to let our less experienced users benefit. Since the users that apply mostly direct formatting don't know about the difference of direct/style based formatting, and the ones who know do very well ... I'd like to throw in a simple Clear Formatting. Maybe this is far from what you've intended, and in 50% in all cases I'll regret any statements made after midnight ... so I better shut up ;-) Best regards. Thanks for the discussion! Kind regards, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] remove Improvement Program feature?
Hi Andreas, I don't whether I have a say here, but please keep the Improvement Program - it'll be very valuable. Instead, I would appreciate to have an Easy to Hard Hack to get some backend working, so that the community can work with the data that is provided by this feature. It worked very well for OOo, so I'm sure there will be a lot of benefit. Especially, since it had been highly accepted by our user base. For LibreOffice, we may detail what has to be done ... but generally, I'd like to keep it. Cheers, Christoph Am Mittwoch, den 19.01.2011, 14:45 +0100 schrieb Andras Timar: Hi, While I was reading the help and looking for references to OpenOffice.org I found a whole section about Improvement Program. It collect anonymous statistics about how the software is used. The data is used to identify usage patterns. This feature is disabled in LibreOffice. Shouldn't it be removed from the source (including help, l10n, option panel, etc.)? I can add an Easy Hack, if you agree. Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Features enterprises will love to have in LibreOffice
Hi Olivier, great stuff - thanks. I had a nice chat with Michael, and it seems that I can also provide some things that have already been specified and are highly demanded. Since I'd like to put this in context, I'll add this when I feel better (canteen food issues? *g*). Cheers, Christoph Am Mittwoch, den 19.01.2011, 08:23 -0200 schrieb Olivier Hallot: Hi I have collected some features enteprises will love to have implemented in LibreOffice and listed them in http://wiki.documentfoundation.org/Development/Crazy_Ideas#Features_Enterprises_Will_Love_To_Have_Implemented Some are quite easy to implement, other may require a longer time for development, but all are based on real demand from people that use LibreOffice in a enterprise production environment. That is, they are not crazy ideas at all. :-) Regards ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MimeType icons - format and naming for inclusion in package?
Hi Kami, thanks for your offer :-) Am Mittwoch, den 19.01.2011, 15:21 +0100 schrieb Kálmán „KAMI” Szalai: Hi Christoph, Your work looks outstanding, congratulation. Only only note of mine that the icons of templates are very similar to normal documents. Cool that you like it - the thanks have to be spread among several people at the Design Team list. There has been a lot of great feedback and some people who contributed I think we should change templates icon a bit to make them visually more separated. What about to put a wider strip to the top of the icon? It can be as wide as the earmark with same color. Oh yes, still a problem ... we had quite some discussion to make them more unique (there is some feedback on [1]), but we failed (in the given time) to harmonize that with the document symbol. As long as we use these (with regard to the branding planning, two or three releases) ... But - now the good message - most of the template icons are presented in context. So, the Templates and Documents dialog provides a lot of clues to make people aware. However, I don't like to talk like that - since the issue remains ;-) On the other hand, some people thought that we shouldn't miss the opportunity to do something unique - spreading the Document Foundation message among the desktops. We'll have a look at that, I'm sure. Until then, how about looking whether they work at all ... I can help to integrate it to the git repo. But here we should define deadline. Maybe we want it to put to 3.3.0 ar 3.3.1 is sufficient? Oh, thanks! In the meantime, Thorsten was so keen and created an issue among with some patchsets (as far as I understood). But, sorry, I didn't think about reporting back ... I feel a bit lost in discussions on another mailing list. Here is the issue: https://bugs.freedesktop.org/show_bug.cgi?id=33229 Maybe Thorsten can comment if things are missing at the moment ... KAMI Again, thanks! Cheers, Christoph [1] http://wiki.documentfoundation.org/Design/LibreOffice_Initial_Icons#Feedback 2011-01-16 22:59 keltezéssel, Christoph Noack írta: (CCing Design Team mailing list) Hi Developers! Sorry for bothering you ... but we'll bother you nevertheless :-) So guys, please have a look at the request by Bernhard (below), since we rely on your support to make LibreOffice visually distinctive. Why? Because the currently packaged icons refer to the wrong product - using the (so called) Sun S-curve, adding OOo Galaxy Style colors and adding seagulls. Concerning the latter, and since I consider myself to be an animal lover, I'd like them to release them into nature ;-))) Here is the current state of our work: http://luxate.blogspot.com/2011/01/libreoffice-initial-icons-milestone.html Finally, and since you already put so much energy into LibreOffice, please support us to make users aware of that! Cheers, Christoph Am Donnerstag, den 13.01.2011, 18:40 +0100 schrieb Bernhard Dippold: Hi all, the LibreOffice Design Team is working hard to finalize an iconset containing MimeType icons for application/documents and templates in order to replace the present icons from OOo 3.0 to 3.2. If you want to have a look at the present state, please visit the wiki: http://wiki.documentfoundation.org/Design/LibreOffice_Initial_Icons#Present_State_of_the_Icon_Design We don't know if there will be a chance to integrate them in the final release for LibO 3.3.0 (this will have to be decided, when the iconset is ready), but even if they make it in LibO 3.3.1 only, we need to know how to format the icons and what are the names to be used for easiest packaging. The ODF icon page [1] shows several file names (probably used in OOo). Are they the same in LibO? With the proper information the design team will try to provide the icons in the best possible way. Best regards Bernhard ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MimeType icons - format and naming for inclusion in package?
(CCing Design Team mailing list) Hi Developers! Sorry for bothering you ... but we'll bother you nevertheless :-) So guys, please have a look at the request by Bernhard (below), since we rely on your support to make LibreOffice visually distinctive. Why? Because the currently packaged icons refer to the wrong product - using the (so called) Sun S-curve, adding OOo Galaxy Style colors and adding seagulls. Concerning the latter, and since I consider myself to be an animal lover, I'd like them to release them into nature ;-))) Here is the current state of our work: http://luxate.blogspot.com/2011/01/libreoffice-initial-icons-milestone.html Finally, and since you already put so much energy into LibreOffice, please support us to make users aware of that! Cheers, Christoph Am Donnerstag, den 13.01.2011, 18:40 +0100 schrieb Bernhard Dippold: Hi all, the LibreOffice Design Team is working hard to finalize an iconset containing MimeType icons for application/documents and templates in order to replace the present icons from OOo 3.0 to 3.2. If you want to have a look at the present state, please visit the wiki: http://wiki.documentfoundation.org/Design/LibreOffice_Initial_Icons#Present_State_of_the_Icon_Design We don't know if there will be a chance to integrate them in the final release for LibO 3.3.0 (this will have to be decided, when the iconset is ready), but even if they make it in LibO 3.3.1 only, we need to know how to format the icons and what are the names to be used for easiest packaging. The ODF icon page [1] shows several file names (probably used in OOo). Are they the same in LibO? With the proper information the design team will try to provide the icons in the best possible way. Best regards Bernhard ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-design] Change application background [was: How to contribute ?]
Hi Rahul, hi community! Am Samstag, den 08.01.2011, 02:05 +0100 schrieb Bernhard Dippold: Hi Rahul, all, Rahul Prasad schrieb: [..] * I was thinking of a nice background instead of a static colour. You can find some of my design here http://rahulprasad.com/public/libreOffice/writer/ Although design is not very appealing, but I am sure people will come come up with better design.* This idea has already been presented some time ago in the OOo UX project, but has not been implemented by now (AFAIK). I can't find the proposal right now, but I'm quite sure, Christoph knows where to find it. That's one small step for developer, one giant leap for LibreOffice. Well, maybe ;-) Bernhard, you are right, this idea has been discussed several times - and I also have some ideas how we can bring LibO forward and make a really thrilling community driven branding. But, this requires some developer support ... The very first step is, indeed, to know how much effort it required to show graphics (whatever kind) on / instead of the application background. Here is the mail by Johannes Eva, who collected some information on that (2009-07-31, ux-discuss list): Hi everybody! Some weeks ago I started to write an article about the application background in OOo. I had time to finish it yesterday night, so here it is! http://www.johannes-eva.net/2009-07-new-application-background-ooo (Christoph: Updated link, since blog engine has been changed.) Here are the two related issues: Change the OpenOffice.org Background Color http://qa.openoffice.org/issues/show_bug.cgi?id=75049 Use bitmaps/patterns/pictures as Application Background instead of plain color only: http://www.openoffice.org/issues/show_bug.cgi?id=103915 Best regards, Johannes When we talked about the StartCenter, Ivan (who is currently busy by shaping the visual design for the revised LibreOffice website) brought up the following idea: http://wiki.services.openoffice.org/wiki/File:Ivan_StartCenter_Proposal_wireframe.png In context, it is on our proposal collection page for the StartCenter: http://wiki.services.openoffice.org/wiki/User_Experience/StartCenter#Mockups [... explanation concerning LibreOffice development ...] I don't know if this feature is easy or hard to implement, but perhaps it can be added to the list of easy hacks: http://wiki.documentfoundation.org/Development/Easy_Hacks Ouch! Some time before (2007?), I have been told that changing anything which is beyond the document border is pretty hard. I would be more than happy if anything can prove this to be wrong ;-) This (for example) is the reason for not having shadows on the right side for the Writer comments/notes (instead, we live with 80's style shadow for the pages). [...] Regards, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] UX New layout Move/Copy sheet in calc
Hi Joost, all! Thanks for your work! I'd like to help, but I rely on your help to understand how currently looks once it is compiled ... :-) So please bear with me. Am Mittwoch, den 05.01.2011, 21:57 +0100 schrieb Joost Eekhoorn: Michael, Sorry that I used the background color directly. I just do not known jet how to use themes. Is there a theme for displaying a warning label in a dialog? I'm not aware of such a theme or specification. I've seen that there is something similar if certain settings (Tools -- Options) are locked down by an administrator. Maybe something to get some inspiration? The color of the warning was inspired by the spec: http://wiki.services.openoffice.org/wiki/User_Experience/Projects/NonModalMessageSystem#Step_2_-_Message_Style_2a Oh, this is not even a spec at the moment - it is work in progress, and the colors have been proposals by Stella. As the others already (implicitely?) mentioned, there is no consistent way to handle that in LibreOffice. We might work on that, if you like. But in the meantime I'd like to propose a rather conservative handling, if we miss the applies to other problems as well solution. Where can I find the specs for the UI and UX for LibreOffice? Sorry, I had to smile ... It's great that you are asking for the specs, but this young project doesn't offer things like that (yet). Usually, I refer to the OOo specification project http://specs.openoffice.org ... but this will (hopefully) change. In the meantime, feel free to ping the Design Team mailing list :-) Concerning the colors - when I've worked on the Writer Notes, I've done some summary concerning the available colors within OpenOffice.org. Maybe this helps to derive colors that are consistent with other parts of LibreOffice: Blog Posting http://uxopenofficeorg.blogspot.com/2008/09/interiour-decoration-colors-of-new.html Notes2 Design Colors http://wiki.services.openoffice.org/wiki/Notes2_Design_MainColors And some more ... OOo Galaxy Colors http://ui.openoffice.org/VisualDesign/OOo_galaxy.html#colors OOo Chart Colors http://ui.openoffice.org/VisualDesign/OOoChart_colors_drafts.html OOo Base Report Creator Colors http://ui.openoffice.org/VisualDesign/OOoBase_colors.html Cheers, Christoph Best regards, Joost 2011/1/5 Michael Meeks michael.me...@novell.com On Tue, 2011-01-04 at 23:03 +0100, Joost Eekhoorn wrote: Thanks for making the improvements. I haven't found a way to change the color of edit box either, so we can leave that a future project for now. Setting the background color is what I have used for the warning Soo ... in general setting manual colors that don't come from the theme is a disaster area for accessibility. aFtWarn.SetControlBackground( Color( COL_YELLOW ) ); There are whole schools-fulls-of users in the tropics that explode when they see the color yellow :-) [ or something like that ]. Seriously; any color we use for highlighting (or whatever) should come from the defined colors used for the rest of the app, and thus from some sort of system theme (ideally). That way it can be changed to be high-contrast / low-contrast etc. This is in part why you tend not to see yellow entries left/right :-) HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Forwarding cell grid question (was: Re: [libreoffice-design] LibreOffice Calc - Cell background color + default cell border)
Hi Ferenc, all, forwarding to libreoffice@lists.freedesktop.org ... There has been a question on the design team mailing list concerning the cell grid - it seems to be drawn in the background, thus, it vanishes if people apply a background color (see picture link below). I don't know whether this is intentional, a bug, ... so I though it's better to ask you. From my UX point-of-view, the grid should be shown on-top. Thanks in advance! Cheers, Christoph PS: I'll moderate answers to des...@libreoffice... Am Donnerstag, den 06.01.2011, 17:38 +0100 schrieb Ferenc Gyenezs: Hi! My question is, is there any way to turn the default cell border always-on-top / show even, when the cell got a background color? http://dl.dropbox.com/u/2842728/grid.jpg I really want to leave OOCalc alone, but i use a lot of cell coloring, and this feature is annoys me. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Standard-color-palette-updates
Hi Kami! Am Freitag, den 07.01.2011, 10:54 +0100 schrieb Kálmán „KAMI” Szalai: Hi Christoph, Bernhard, LibO Gurus, Then I provide patch for removing colors from main palette, and create/update a separated palette. Is it okay? That would more than okay, that would be great! :-) And towards all the LibO Gurus (incl. you, Kami), is there any way to add a (visible?) comment within the color palette? As Bernhard mentioned, the colors will change ... for sure. I was able to add something like that to the GIMP Palette (Extract): GIMP Palette Name: LibreOffice Initial Branding Colors (November 2010) Columns: 8 But I am unaware whether the LibO/OOo XML (.soc) can handle that. Moreover, it would be great if somebody could check the XML for validity, since I badly hacked it (without that much XML knowledge). At least, it loads and works (for me). Again, here is the link the most recent files in the TDF wiki: http://wiki.documentfoundation.org/Marketing/Branding#Resources_3 Thanks! Cheers, Christoph 2011-01-07 03:15 keltezéssel, Bernhard Dippold írta: Hi Kami, all, Kálmán „KAMI” Szalai schrieb: Hi All, Some colors of LibO are already part of palette, I just wanted to update it to follow the latest colors in wiki. If not required to provide LibO colors with the product (as a main or separated palette) then I we can leave the current situation or roll back. I would like to provide these colors but this is one opinion :o) My personal opinion is near to Christoph's position: We can't grant that the present LibO colors will stay the official branding colors when the community based branding will be developed (planned for LibO 3.5). Changing colors while keeping their names is a no-go IMHO, because this would lead to modified documents when opening them with different versions of LibO. As Christoph mentions, the LibO colors are relevant for all the people trying to create documents and artwork following the present LibO branding, but these people are a minority against all our standard users. Therefore I would love to see these colors in an additional palette, but not in the main palette (perhaps except the main color LibreOffice_Green1). Best regards Bernhard PS: If we provide the colors, we should ship the final version you got from the wiki - thanks for your work on this topic! ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Robert, all! Am Mittwoch, den 05.01.2011, 18:32 +0100 schrieb Robert Nagy: Oh well then Linux is broken, again. :) In gedit the icons are bigger than the small ones but not as huge as in LibreOffice. Here you can see (LO with small icons): http://blade2k.humppa.hu/2011-01-05-182917_1920x1080_scrot.png Mmh, I'm unsure how much it helps to compare the different applications. * gedit is a native Gnome application and respects their desktop guidelines. -- 24x24 px toolbar icons, text below (always) * Firefox is a multi-platform application that (most of the time) respects platform specific rules -- 24x24 px toolbar icons, no text (which seems to be the default for Firefox) * LibreOffice is also multi-platform, but we care less about platform specific characteristics (mainly driven by saving effort ... for Windows, sharing toolbar and menu icons - no further comment on that) -- 16x16 px toolbar icons, no text As said, our small toolbar icons are 16x16 px, the larger ones are 26x26 px. Thus, there is no way to perfectly align LibO/OOo to what the Gnome Desktop defines/requires. Moreover, one of our main problems is, that we do offer too many toolbar elements per default ... thus we have to omit the labels and hitting the buttons gets harder (due to their small size). Increasing the icon size (better: automatic setting) will improve that, but we won't improve the understandability of the metaphors :-) Here is some more information ... Platform Differences (scroll a bit down, please) http://wiki.services.openoffice.org/wiki/Platform_UI_Differences#Differences How Toolbars and Labels are Used within Gnome http://library.gnome.org/devel/hig-book/stable/toolbars-labels-tooltips.html.en (ws robert 22435)$ xdpyinfo | egrep (dimensions|dots per inch) dimensions:1920x1080 pixels (518x291 millimeters) resolution:94x94 dots per inch It is strange for me tho that linux *hardcodes* 75. Where is taht hardcoded? I don't know whether this helps in general, but in Gnome there is a DPI setting that is used to scale the font display. At least for my screen is 96x96 DPI (using the command above). Cheers, Christoph On (2011-01-05 17:14), Michael Meeks wrote: Hi Robert, On Wed, 2011-01-05 at 16:24 +0100, Robert Nagy wrote: On (2011-01-05 14:27), Michael Meeks wrote: So - I would prefer to stick with large icons; and not use the DPI setting. I suggest instead, that we only use large icons if the true Y resolution 768 - how does that sound ? Oh wait, I misunderstood. That is wrong. I am on a 1920x1080 display :-) so - as I say; the DPI is a constant of 75 across the Linux desktop, so this is not a switch but a hard coded setting :-) I am still convinced that large icons, on a reasonably sized screen give a -far- more useful view of the metaphore for a beginner user. As I say, advanced users can make it smaller. and i still prefer the small icons, it is like that in _every_ app. So we should stick to the DPI. Well; looking at gedit - it is using gtktoolbar.c's: #define DEFAULT_ICON_SIZE GTK_ICON_SIZE_LARGE_TOOLBAR ie. the same size (large) icons that we are using here. Perhaps the size setting is coming from the theme, in which case we should extract it and use exactly that setting in LibreOffice - can you have a dig ? (can you check that stock gtk+ apps do indeed have small toolbar icons ?). Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] set the icons size based on the DPI just like we do on Mac
Hi Christian! Am Mittwoch, den 05.01.2011, 19:40 +0100 schrieb Christian Lohmaier: Hi Christoph, *, On Wed, Jan 5, 2011 at 7:18 PM, Christoph Noack christ...@dogmatux.com wrote: [...] Mmh, I'm unsure how much it helps to compare the different applications. * gedit is a native Gnome application and respects their desktop guidelines. -- 24x24 px toolbar icons, text below (always) Well - not always. [...] You are right, maybe my always wasn't waterproof :-) There is also a setting that shows labels only for the less known/used icons - I wanted to say that the labels are shown for all toolbar icons. Anybody remembers IE5? :-) Sorry for the misleading formulation... Moreover, one of our main problems is, that we do offer too many toolbar elements per default ... thus we have to omit the labels and hitting the buttons gets harder (due to their small size). I disagree Hitting a button that is still 16x16 is not hard (on 1680x1050, even less so on smaller resolutions) unless you're disabled in some way, but in that case you probably use a bigger theme anyway. I disagree as well :-) http://en.wikipedia.org/wiki/Fitts%27s_law Hard might also refer to the effectiveness (speed) and/or the effort (likeliness of RSI) that is required to use a device that controls the mouse pointer (even via touchpad and/or TrackPoint). Example: People using their laptop in the train - in comparison to the desktop at home, one is confronted to environmental constraints (bumpy road), an incorrect body posture, and different / less accurate input devices. Thus, we have to take care that our default settings work well for the majority of users working in very different working conditions. By the way, even if some people don't like the idea - this is what Microsoft managed rather good with regard to the ribbons (MS Fluent) and the visual distinction (size, labeling) of the different toolbar buttons. [...] Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [UX] Formula cursor proposals (was: Re: Formula cursor : bug or feature ?)
Hi Regina, hi Jan, and of course Jonas! Jonas, first - thanks for working on such a great feature. Due to this thread, I noticed the video presenting the feature (moreover, YouTube also proposes some catwalk clips *g*). Cool! I briefly went over the thread and I really understand most of the concerns mentioned here - but I don't see any (really) conflicting issues. Or at least, that should be solvable somehow. @ Regina, Jean-Baptiste: Right, the opportunity to jump to a certain cursor position within the formula syntax is very helpful for advanced users. After having worked a lot with the command window during my studies, I prefer typing than clicking. The problem is (same for e.g. the page preview), that this functionality is invisible. Most of the students I knew, did not get an introduction how to use a Formula Editor ... @ Jonas: You are right as well - it is indeed more than helpful for less experienced users (who start to work with the command window) to edit formulas more visually. But also experts will value advanced visual clues (since jumping to a certain formula position is one of the basic things that already worked). The main issue is, that we do have two different input methods (one being WYSIWYG, the other one being the formula syntax) that have to be synced somehow. The content itself isn't the main problem, but things like cursor position and selection. We can only have one, because this corresponds with the current focus that is visualized for the user. So here is some initial idea that might serve as some input to solve that issue. It already implies some step-by-step approach to achieve reasonable maturity: * Only one item (visual editor, command window) can be active at a time. There is a need to switch between both input methods. Let's call that new functionality change editor focus * Change Editor Focus: The focus changes to the other editor. The cursor position position / selection marker is transformed to and visualized within the (now) active editor type. * Behavior: * If the command window is currently inactive and the user clicks inside the command window, then the Change Editor Focus is executed. * If the command window is currently active and the user clicks inside the command window, then the cursor is placed according to the mouse pointer position. * If the visual editor is currently inactive and the user clicks inside the visual editor, then the Change Editor Focus is executed. * If the visual syntax editor is currently active and the user clicks inside the visual editor, then the cursor is placed according to the mouse pointer position. * Keyboard Shortcut for change editor focus: Provides a shortcut for the advanced users ... * Proposal 1: Ctrl+Tab could be used if it does not interfere with a (planned) syntax completion. In Calc, STRG+Tab (e.g.) cycles through the elements within the formula bar (once having the focus). * Proposal 2: Ctrl+Shift+F2 is used in Calc to jump to the input line (but not back) and may be used here to cycle between formula syntax input and visual input. * Proposal 3: Add yours, here ;-) * [Optional] To make the feature more visible for all users, by avoiding too much clutter in the application menu, I propose to add a context menu entry to both the editors that says something like Go to Formula Object / Go to Commands Window (the official name in the help). A context menu is mandatory anyway, if Copy/Cut/Paste is available for the visual editor. * [Optional] Visual Indicator: Advanced users might even value some always visible visual indicator for the current position - extending the current [], ?. How about a gray dashed line that surrounds the currently active element when working in the command window? (Is this what you name care at [1]?) Note that I disrespect the initial user intention for the clicks (like Firefox does for the search field, well, not really) ... we should check whether this is accepted / understood by the users. At the moment, it is a rough guess that this might work (well). If not, I do have some more complex (but working) ideas. Comments appreciated :-) Although it might take some time to get back to this discussion ... At the moment, there are still
Re: [Libreoffice] [PATCH] Standard-color-palette-updates
Hi Kami, my apologies ... having only brief looks at certain topics does not really help :-\ I thought the original color palette won't be affected at the moment, since the branding colors are: * not that long lasting (belonging to the initial branding, but will be replaced with the community branding once we start to develop that with the wider community) * are specific to a small group (the LibO community) Thus, my understanding was to ship the original color palette file like some others - being optional and not affecting the default palette. Our normal users don't have that much benefit creating stuff with that few (hand picked) colors. I am wrong (rhetorical question, since your answer already conveys that I am wrong... *g*)? If yes, what is the plan? :-) Cheers, Christoph Am Montag, den 27.12.2010, 09:21 +0100 schrieb Kálmán „KAMI” Szalai: Dear Christoph, I wanted to include the original palette, but: * This palette is not complete, I miss some other cool colors * For compatibility reason I would like to keep the legacy palette * For consistency I would include Chart color too If you want I would create patch that contains the LibreOffice colors, then chart colors and finally the legacy color palette. Best regards, KAMI 2010-12-25 15:29 keltezéssel, Christoph Noack írta: Hi Kami, having just 30 seconds left until my family wants to see me again (*g*), I'd like to refer to the color palette we already provide for download (we try to keep this up-to-date as well). Maybe this eases the work on this issue ... does it? http://wiki.documentfoundation.org/Marketing/Branding#Resources Kind regards, Christoph PS: I've noticed that anybody updated the name of the list (now: LibreOffice ML), but the subject line still states the wrong Libre_o_ffice. Who is the one who should be bothered? Am Samstag, den 25.12.2010, 09:52 +0100 schrieb Kálmán „KAMI” Szalai: Hi All, Palette updates based on http://wiki.documentfoundation.org/Marketing/Branding#Colors Also I put space beween Libre and color name. Please review it and apply if you like it. Best regards, KAMI ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] [PATCH] EasyHacks 3.27 Change Sheet copy process
Hi all! Since the rest of my family is sleeping now, there are some minutes left ... but I expect my nieces to get me out of the bed in a (very) few hours. Thus, shortened answer :-) Am Mittwoch, den 22.12.2010, 11:03 -0500 schrieb Kohei Yoshida: [...] Another thing would be helpful ... a more instant feedback on name conflicts: showing a comment below the name text field, deactivating the OK button. The /!\ symbolizes a small warning sign. Ah, good. Great minds think alike. :-) Regarding the /!\ warning symbol, can you think of any existing dialog that does that? I like the idea itself, but I don't know how that could be (easily) implemented. Looking at an existing dialog code would help me figure out how to do this. At the moment, I don't know any existing dialog within LibO ... maybe (sort of) the Tools -- Options dialog that (if I remember correctly) shows some messages if certain options are locked down by administrators. But, maybe the ongoing effort within the OOo UX team might help us. It doesn't fit perfectly, because the invalid name is persistent but the info bubble is designed to appear temporarily: http://wiki.services.openoffice.org/wiki/User_Experience/Projects/NonModalMessageSystem#Step_2_-_Message_Style_2a * Think about the Insert Before thing ... it is not that obvious what this means. Is there any way to make this more understandable? Hmm. This needs some thinking. I'll comment on Joost's proposals in his mail ... * Does any data / experience prove that the default (new) position of the sheet should be directly after the source sheet? I didn't see any usage data in the spreadsheet file I downloaded from here http://wiki.services.openoffice.org/wiki/File:OOo31_Usage_Feedback_Data.ods Anyone is welcomed to double-check it though. I downloaded the file at the top of the list and had a look at the Calc sheet. It seems that most of the stuff is still German - so I just looked for items that contain move. For example (sorry, no deep-dive), I found the following (seems to be checking the button copy within the dialog): TabelleVerschiebenKopieren-Kopieren sc:CheckBox:RID_SCDLG_MOVETAB:BTN_COPY Check 2352 Did that help ... even if I just throw in some late ideas? ;-) Yes, it did. I guess we have some further work to do in this dialog. :-) Wait, wait ... I have more ideas for even more dialogs ;-))) Thanks a lot to both you Kohei, and Joost! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] [PATCH] EasyHacks 3.27 Change Sheet copy process
Hi all! I'd like to comment the button up/down idea ... maybe the questions are already solved somehow, but just to be sure ... Am Mittwoch, den 22.12.2010, 11:22 -0500 schrieb Kohei Yoshida: My preferred approach is to create two buttons to move the insertion position up or down, instead of relying on the user clicking on the sheet name in the list. To me 1) that makes more sense, and 2) is easier to implement than handling mouse click events on the list control. Here we face the ease of use vs. efficiency issue ... the proposed approach might fall short for the power users. Ease of use: If a document has a limited number of sheets, and the user is rather mouse-driven, then clicking three times or so is okay. As we said before, the result is directly visible and, thus, an improvement ... Efficiency: Some users (more advanced users) that work in large tables might simply prefer to scroll down via the mouse-wheel, and to directly click on the target position. Concerning the latter, if we want to have something like that (and there will be requests to mimic the today's behavior), we require space consuming placeholder lines between the real sheets. This somehow disturbs the known sheet mapping ... and even for our ease of use proposal, the users have to re-think the mapping (horizontal vs. vertical). Furthermore, let's assume that a less experienced user misses the current dialog design and moves a sheet to the wrong position. Then both the actions move/copy are non-destructive (looking at the data that is kept after all). So correcting this issues might a smaller problem - in comparison to what we can gain for power users. Finally, the current design is not that bad ... if we want to go for a design that suits the non-experts, then we also have to keep in mind the power users. Does that make sense to you? I'll try to think a bit more about this issue ... By the way, if buttons get added, please consider to add them at the right hand side (if possible, I'll double-check this with other specs). And, they should be in close relationship - to make sure that the required mouse movement is minimized, e.g. if the user wants to correct the usual one click too far issue. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [UX] Re: Better wording for 'Update links' question
Hi David, all! Am Mittwoch, den 22.12.2010, 11:56 +0800 schrieb David Nelson: Hi, :-) So, re-working Hal's suggeston, we'd have: ??? This document contains one or more links to external media or other data. Do you want to update all links to get the most recent content? Go to Edit - Links... to find out what external data this document references. I think this proposal misses a bit the remaining LibO/OOo menu and dialog wording. For example, the external media or other data is is External Data in Calc. And, as far as I know, LibO/OOo rather uses Media and Sound or Objects, but doesn't refer to media. The funny thing is, that pictures (the media content) won't get updated within this dialog - so it would be somehow incorrect. I assume that it is the same for videos and sounds. Then, I miss the reason for asking - it is implicitly contained in most recent content, although the external data might not have changed in the meantime. And what happens if the user does not update all the links? Then I'd like to ask whether you plan for different buttons and/or dialog titles - or is this the default Yes/No behavior? If yes, then the user would get the important information in the second part. It is usually recommended to provide it as early as possible. That's e.g. the reason for the self-speaking buttons. (I agree that LibO/OOo still misses such specific dialog guidelines like the Gnome HIG or stuff Apple/Microsoft/... provides.) The last sentence Go to Edit ... is I'd like to see in the help (referring to a sub-section to the , but not in the dialog itself. But to be honest, I don't know whether there is currently a help topic for that ... Until then, I'd stick with the proposal stated below. Cheers, Christoph On Wed, Dec 22, 2010 at 09:27, Christoph Noack christ...@dogmatux.com wrote: [...] Update Linked Data This document links to external data that might have changed. Do you want to update all linked data or keep the current document content? [Help] [Update] [Keep] [...] ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Better wording for 'Update links' question
Hi Kohei, hi Joe, all! Am Mittwoch, den 22.12.2010, 15:11 -0500 schrieb Kohei Yoshida: On Wed, 2010-12-22 at 13:06 -0500, Joe Smith wrote: On 12/21/2010 12:09 PM, Jan Holesovsky wrote: Hi, https://bugs.freedesktop.org/show_bug.cgi?id=32548 The bug says: when I open a certain .odp document, I get a pop-up question asking Update all links? Yes/No Anybody who knows this functionality, can you please provide a better wording? ;-) Just post it here, I'll integrate it. Thank you a lot, Kendy Believe me, I'm no fan of this cryptic prompt, but I'm afraid this won't be an improvement. The wording of the prompt is not the primary problem. I'm not sure if I agree with that view. This *will* be an improvement, and although the wording alone will not be enough to fix this *completely*, improving the wording itself is a step in the right direction. +1 Experts already know what Update links? means; non-experts will not understand enough to answer the question correctly even with improved wording. I disagree here. You tend to polarize the users as either experts or non-experts. There are those in between who want to make an informed decision and will understand the verbiage. The user who reported the above bug is one such example. Let's assume that we do have a so called non-expert here - since we offer a modal dialog, what will he do with the current dialog? There is no escape, he is forced to make an uninformed decision. That is (one) reason why the proposed dialog contains a [Keep] button that sounds somehow safe to click at - in any case. All we accomplish by changing the wording is to make everyone read and deal with a longer and more complicated (and common!) No, making the warning verbose does not make everyone read and deal with it. Those who ignore such warnings will continue to ignore it just as easily even with a longer warning. And the new wordings proposed so far are not even that long. To the initial statement everyone read and deal with a longer That is incorrect, as long as you refer to the text only. A dialog provides some more ways to add information. As I said before, more advanced users will benefit from the new buttons and the new dialog title. Moreover, such dialogs tend to be like words in the end - you don't read the text, once you've memorized the dialog you guess based on the known shape and overall appearance. [...] Would it be possible to have the prompt remain as it is, with a Help or More button that leads to some expanded explanation? Given the fact that the More button might only show some few lines of text - what does that additional click help? But, you are right, that OOo/LibO has some of the most awkward dialog concepts we can find today ... but let's first listen to Kohei. Relying on help for everything is a recipe for making poor UI. Help is a last resort, and we need to do our best to design UI so that the user won't have to rely on Help. In some situations we do need to rely on help to convey some complex scenarios to the user, but I don't think updating external links is one such example. One thing I may agree is that maybe we need to have a two-level warning system that displays a summary of the warning, and the Detail button to show more information. But we don't have such dialog implemented yet (feel free to correct me here), and until we do I would favor showing a more verbose and informative warning message than the current terse message that leaves some users confused and clueless. Please look at 3.4.1 Alert Text in the Gnome HIG: http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#alert-text Since the Gnome guys are known for good usability, let's assume that this dialog design is well proven. There is: * Icon (not important, here) * Primary text (large size) * Secondary text (small size) * Buttons (might use custom caption) This is a design we might go for - but technically, this hasn't been possible in the past. There has been a discussion on OOo ux-discuss (but I don't find the original message), where we added some additional text within the dialog. A bad solution, but less bad than not addressing the problem ... So - if possible - please let's smoothly transition to that kind of dialog content in the future. Although this will be hard for the translation, because some of their translation memory won't work (since there are more individual strings). But Joe, you talked about the perfect solution - of course we may head towards an ideal world in several steps. Ideally, Calc would automatically detect whether the external data resources are available and if they perform well. If yes, then Calc will automatically update the data - and the user won't even notice that. If there are problems, then the document will open anyways, but Calc might inform with a non-modal message that some parts might not be up
Re: [Libreoffice] Better wording for 'Update links' question
Hi Kohei! Am Dienstag, den 21.12.2010, 14:24 -0500 schrieb Kohei Yoshida: Given this, I don't know what the better wording would be. Updating all links basically tries to fetch the latest content from the respective link sources, or else the app would show data from its own cache which is normally stored with the document, and may be outdated. How about this? This document contains one or more links to external data. Would you like to update all links to get the most recent data? Go to Edit - Links... to find out what external data this document references. Much, much better! Is another iterative proposal okay? Assuming that we might use self-explanatory buttons ... and that I need somebody who resolves the non-native speaker language issues ;-) Update Linked Data This document links to external data that might have changed. Would you like to update all linked data or keep the current document content? [Help] [Update] [Keep] By the way, another item that might greatly benefit when using non-modal messages ;-) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] [PATCH] EasyHacks 3.27 Change Sheet copy process
Hi Kohei, hi Joost, hi dev list members! It seems that I still miss a good way to sort and highlight IMAP messages - I did not pay too much attention to this thread and totally missed the CC Christoph. Grrr sorry at the same time ... Thus, I don't know whether this is helpful at the moment (as far as I understand, the patch has been already committed), but here are my short thoughts ... Bur first, a basic question: Did the change address a small (but important) issue, or is the change part of some broader attempt? I ask, because the dialog is rather old and contains some other issues (like the old vertical OK/Cancel/Help design). Am Freitag, den 10.12.2010, 20:31 -0500 schrieb Kohei Yoshida: [...] About UI I'll refer to your (Kohei's) pictures linked in another mail ... And these are the screenshots of the new dialog. Rename unchecked http://people.freedesktop.org/~kohei/sheet-rename-unchecked.png Rename checked http://people.freedesktop.org/~kohei/sheet-rename-checked.png Two main (and somehow rhetorical) questions / remarks: * If the user copies a sheet (several sheets) within the same file, then the new sheets will be renamed anyway. Right? Although the user did not check the Rename checkbox ... -- As far as I understand, we require unique sheet names. The checkbox refers to a user intended name change. * If the user copies a sheet, how will he get aware of the name of the new sheet? -- Currently, people have to finish the operation and then look for the new name. * Let's remove the 'New Name' string as I feel this is redundant. And let' place the rename box either to the immediate right of 'Rename' check box, or immediately below it. I prefer it being to the right of the check box since we have a plenty of space there. Does that mean the aligned to the caption Rename? Would be great. * Instead of hiding the rename box, it's better to disable it when the Rename check box is not checked. We generally don't show or hide controls but enable or disable it. * Let's disable the Rename check box as well as the rename input box when multiple sheets are selected. We don't know what we should do for multiple sheet copy/move rename yet, so I would be more comfortable disabling it in such cases (at least for now). Yep. * I think it would be more user-friendly if the Rename input box showed the default sheet name. When moving a sheet, this would be the original sheet name, while when copying a sheet it would be the original name followed by '_' + num (e.g. Sheet1 - Sheet1_1). Absolutely. [...] All in all, I'm happy with what I see there, so, good work! :-) A small additional question (I may have missed that): What happens, if the user choses a name that is already used in the document? The current (less helpful) reaction within the renaming sheet dialog is another dialog window Invalid sheet name. (Ask any user if he knows what this might mean ... *g*). Let me know if you need any help with any of the above items. I'll CC Christoph in case he has some comments on this feature as well as on my comments above. Christoph, please feel free to add your comments as well if you have any. :-) Concerning my questions above, I do have a proposal - it is meant to be a small iterative step, so please look at it critically ;-) Some assumptions: * limit the number of changes * keep the idea of a common move / copy dialog (I still don't know why this had been introduced ... but at least, it saves another menu item) +-+ | Move / Copy Sheet: $sheetname | +-+ | Action -- + |(o) Move | |( ) Copy | | | | Location and Name --- | |To Document | |[ $documentname (Current Document) |\/] | | | |Insert Before| |+-+ | || Sheet 1 | | || Sheet 2 | | || Sheet 3 | | || (move to end position) | | |+-+ | |
Re: [Libreoffice] Better wording for 'Update links' question
Hi Olivier, thanks a lot! So another iteration ... CCing all the other guys and keeping your message. So the new text proposal is: Update Linked Data This document links to external data that might have changed. Do you want to update all linked data or keep the current document content? [Help] [Update] [Keep] Bye, Christoph Am Dienstag, den 21.12.2010, 23:14 -0200 schrieb Olivier Hallot: Hi Em 21-12-2010 20:03, Christoph Noack escreveu: Hi Kohei! Am Dienstag, den 21.12.2010, 14:24 -0500 schrieb Kohei Yoshida: Given this, I don't know what the better wording would be. Updating all links basically tries to fetch the latest content from the respective link sources, or else the app would show data from its own cache which is normally stored with the document, and may be outdated. How about this? This document contains one or more links to external data. Would you like to update all links to get the most recent data? Go to Edit - Links... to find out what external data this document references. Much, much better! Is another iterative proposal okay? Assuming that we might use self-explanatory buttons ... and that I need somebody who resolves the non-native speaker language issues ;-) Update Linked Data This document links to external data that might have changed. Would you like to update all linked data or keep the current document content? [Help] [Update] [Keep] By the way, another item that might greatly benefit when using non-modal messages ;-) Cheers, Christoph As translator I have the UI pretty much in my mind. If I recall, the style form Would you like to... is extremely rare in the UI, and Do you want to... almost used in every case like this. My 2 cents for keeping the UI style uniform. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Extensions manager improvement
Hi Caolán, hi Júlio! Am Sonntag, den 12.12.2010, 20:34 + schrieb Caolán McNamara: What you think about install extensions like in Firefox? I mean, the user just need to open extensions manager, search extensions and click to install. This feature would be great! (my point of view). Also, it checks updates in dictionaries, grammatical rules, etc. Well, I think the checks updates for already installed extensions is already in there, that should work I think. Yep - but of course it requires extensions to be installed that handle the language related stuff. Júlio, if you could work on improving the current Extension workflow - this would be great. Currently, it requires to go to a certain site, filter manually, download the extension to a temporary location, install it within LibO/OOo (if it works and you downloaded the correct version), delete the temporary file. Wow! Firefox (more or less): Open the extension manager, mark one of the highest rated extensions for installation, wait. Done. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Developers, Designers and Vice Versa?
(Note: This mail is cross-posted to both libreoff...@... and des...@...) Hi all, just a short question - is there anybody of you (developers) on the Design mailing list as well? I'm curious, because people (there) start to discuss ideas and sometimes it would be great to get instant feedback on the effort, technical issues, ... another point-of-view. This is step one of my hidden agenda. Of course, if nobody replies, there will be pro-active advertising ... so be warned in advance ;-) Thanks! Cheers, Christoph [1] http://www.documentfoundation.org/contribution/#lists ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Visual Design] Request for Icon Artwork (was: Re: [UX] LO status bar annoyances)
Hi all! I forward this request to the LibreOffice Design Team, okay? Guys, Kohei asks for two icons to improve the current behavior of the status bar. More detailed, it is about the little Document Modified icon that appears if ... hard to guess ... a document has been modified and is not yet saved. There are some issues that might be resolved by having the current indication (that looks a bit too frightening, having a red exclamation mark ...) look like: * Document unchanged: Very (!) subtle document icon * Document changed: Subtle document icon having a kind of yellow star to indicate something is new Details below ... It would be great if somebody could pick that up and either publish it in our wiki (suggestion: in your user page), or directly send it to the developers mailing list for review. Thanks in advance! :-) Maybe large parts of the discussion took place on the wrong mailing list, so you'll find the request by Kohei below (and a link to some initial design drafts). Some more hints: * My original comments concerning (also other parts of the) status bar can be found here. It also contains the rationale to come up with the document style icons: http://lists.freedesktop.org/archives/libreoffice/2010-November/003712.html * Kohei also sent the current files (one being empty, but this should be changed, of course): http://lists.freedesktop.org/archives/libreoffice/2010-December/003777.html * The design of the currently used Zoom slider icons (by Stella) is available here for inspiration (to get an idea about the size and the currently used style): http://ui.openoffice.org/VisualDesign/OOo_icons_zoomslider.html#iconszoom Concerning the latter - the challenge is to create icons that communicate the status information only character. There is nothing executed in contrast to the zoom slider icons being also located in the status bar (please don't ask why it then is still called a status bar *g*). Thanks a lot in advance! Cheers, Christoph Am Mittwoch, den 01.12.2010, 16:00 -0500 schrieb Kohei Yoshida: On Wed, 2010-12-01 at 08:16 +0100, Sebastian Spaeth wrote: Part 2 on the Changed icon part. On Tue, 30 Nov 2010 22:31:44 +0100, Christoph Noack wrote: DOCUMENT CHANGED INDICATION A solution should: * just work * be unobtrusive (don't catch attention if it isn't required, don't waste space) * be self-explanatory (if possible) Right Ideally, we would not need that status bar and change the Save icon depending on whether there are changes that can be saved or not (e.g. overlay it with a yellow asterisk or so). I am one of the persons that agree that the save button should always work. But that doesn't mean that the save button cannot convey information on whether it is currently sensible to do so. (Alternatively gray it out if unmodified, but still allow it to be pressed). This would be my favorite solution. Putting that aside, let's work on making the status bar icon non-annoying, our ideas are pretty much the same. But the current solution isn't perfect, of course. Current issues: * The extended help tip still mentions the '*' for a changed document. Right, tiny issue * For unsaved documents, the normal tool tip mentions The document has not been modified since the last save. (Small issue, may not be changed). I don't have a problem with that, except that I have to mouse over an apparently empty are to see that toolbar. Why not always have an icon that changes appearance? That was my initial idea, but the icon author apparently had a different idea. This is what it looked like originally: http://kohei.us/2009/07/27/hackweek-minor-polish/ which was a bad rip-off of the current save icon, hence updated to the current, new, originally authored icons. Now, as I said in my other post, I would very much like to have someone with good artistic sense to help me come up with new images to replace the current ones. I'll try to find the current images and post them to the list shortly. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Hi all! Am Mittwoch, den 01.12.2010, 08:12 +0100 schrieb Sebastian Spaeth: On Tue, 30 Nov 2010 22:31:44 +0100, Christoph Noack wrote: [...] STATUS BAR For example, the little '*' is mainly caused by the need for a very compact symbol - here, please think in 480px width. Is there still a little *? I've never seen one in current LOs... Nope. I just tried to explain why software makers started to use '*'. To my own surprise, this not that self-explanatory thing survived a rather long time :-) [...] * It provides access to some IMHO rarely used functionalities where I would love to see other things in that space. Has the UI project collected data on how often people *intentionally* :-) changed from INSERT to OVERWRITE mode? Hehe, nice try ;-))) I don't know whether this is collected by the User Feedback program (because: can be changed via keyboard, and such input is usually missed because of privacy reasons ...). However, if you don't observe a subject (a.k.a. user), then it is very hard to know whether a certain action has been intentionally or not. If you get enough data, one can assume that the majority of data collected is based on intentional use. Another alternative is to analyze such data on the what did the user after this or that approach - but such data isn't available to us. Although it is available at Oracle in the real database, we are currently only able to look at plain exports. But, some of the items do serve a different purpose ... please read on. [...] Thanks for the shot, the zoom slider is actually the one thing I use more often and which I am quite happy with. Naively, I would say you don't need + and - buttons if you have the slider available. I could also do away with the percentage number as long as I have the mark at the 100% zoom level as a visual aid. It is great to see the I would, or I use. Because, this is a very personal issue and also dependent on the task people are using LibreOffice for. Thus, the magic is to work out a solution that can be used by the majority of users, for the majority of tasks. Example 1: Having the +/- buttons may be helpful for people whose ability for precise movements decreased. You might have seen the discussion covering accessibility, and design for all. A click on a button is far easier than pressing a key, and dragging the zoom slider. Okay, you might say that simple clicks on the desired position will work as well - but do most people know that? I doubt that, because it cannot be derived from natural / physical objects. Example 2: Buttons may not only be action elements, they do convey information. So removing the buttons - what's left? A zoom slider without any indication what is increasing/decreasing the current view? So removing the icons requires to re-add some other information ... okay, than back to buttons :-) You may notice, that the selection modes thing has been changed, and that all the items in the status bar got their own visual symbol to improve the representation. I also added no outline level (Keine Gliederungsebene) to teach the user what the slot is used for (today, it is empty). This might have helped to reduce the hazzles one could read today on the TDF discuss list [4]. I kind of like the selection icons, what I do *not* like is that a) now 4 buttons occupy space for a rarely used function and b) there is no visual aid as to what these do (the icons look a bit like they could perform some alignment at first glance), so I'd propose to put the currently selected icon in *one* button, which pops up all 4 modes in a vertical row with a Selection Mode header (and a link to the help entry) above it all. As I initially said - today I would do it differently. The original aim of the mockup (with draft icons, by the way) was to come up with the Zoom Slider, but not to change any other functionality. However ... The buttons do convey information - they provide information on modes. Modes change the behavior of the system (here: software), but sometimes it is hard for the user to guess what happened. Thus, it is required to provide feedback ... and may it only be helpful for users to see Oh, that's different this time. What went wrong? The selection mode is one of the bad examples of a less experienced user will never know what happened. One of the funny things to watch are users, that got trapped by the (Shift + Left Alt) language selection within Microsoft Windows XP. A mess ... but we should be careful to remove something which had been intentionally added by Microsoft some years ago. If we talk about being inspired by Microsoft, I would love to ditch some items for a permanent word count as I've seen in MS Office 2010. Much more useful status information. Agreed - the current word count is g. But, since there had been some discussions (e.g. on user lists) when the feature was introduced, I'm not that sure whether it is required all the time
Re: [Libreoffice] High contrast issue
Hi Kendy, hi Jonathan! Am Mittwoch, den 01.12.2010, 15:01 +0100 schrieb Jan Holesovsky: Hi Jonathan, Jonathan Aquilina píše v Út 30. 11. 2010 v 09:28 +0100: Hey guys I am experiencing a really nasty HC issue. Oh dear ... :-) I am using the obsidian theme on KDE. attached find an image that shows what happens. You are unable to see the text, unless you high light it. Hopefully this sheds some light on the issue. As discussed on the IRC, it is because the we don't have HC graphics for the StartPage... Christoph - please, would you be able to provide a version of the StartPage graphics that is black, with the LO logo in white, for the hi-contrast purposes? That might take two days, since I will be offline tomorrow - sorry for the hazzle. But maybe anybody wants to pick that up, so I CC the Design list as well (original thread [1]). Kendy, is there anything special within the original HC graphics for the StartCenter? It would be nice to know whether there have been any modifications concerning the shadows and the like ... here, it is less about the visual artistry, but the picture size - I experienced LibO/OOo to be a bit picky in such cases. But, Michael already talked about some images being removed from the repository. Thus, I can't find the graphics ... e.g.: http://cgit.freedesktop.org/libreoffice/artwork/tree/default_images/brand/shell Since I lack some time (and - as usual - some understanding), could you please provide me some hint what to do? ;-) Thanks in advance! Cheers, Christoph [1] http://lists.freedesktop.org/archives/libreoffice/2010-November/003656.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] Some dirty stuffs around styles in calc
Hi Cedric, since I go through my mails from top to bottom, I'm sorry to say that I now miss the time to give that some thought. But, the good message is, tomorrow will be our department Christmas party ... plenty of time to think about such issues :-) I'll be back ... if not, please ping me, okay? Again, sorry ... Cheers, Christoph Am Mittwoch, den 01.12.2010, 14:38 +0100 schrieb Cedric Bosdonnat: Hi all, The other day when playing with a calc document, I discovered an annoying feature. Create a new spreadsheet, protect one of the sheets and try to modify the cell styles: nothing shows up when clicking on the Modify... context menu. I had to run a debug session in sc to understand that the problem was caused by a protected sheet... which obviously normal users won't do. I see here several usability problems: 1/ The Modify... context menu should be at leat unactivated 2/ You can still create new styles 3/ You can't even edit styles that aren't applied in the protected sheet 4/ There is no visual feedback for the user to understand what happens What's your take on this? Christoph, do you have any idea to improve that thing? Regards, ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [UX] LO status bar annoyances
Hi Thorsten, hi Sebastian, all! :-) Am Dienstag, den 30.11.2010, 12:00 +0100 schrieb Thorsten Behrens: Sebastian Spaeth wrote: Am I the only one finding the current status bar pretty much useless? Nope. I hear you, pretty much unconditionally. Adding UX tag Cc-ing my favourite UX homie. :) I hope you know to whom you sent your mail ;-) But, mmh, since we finally want to come in touch with some more UX guys, how about adding the Design mailing list for such issues? Although I'd like to refer to some of the issues already discussed here, I feel free to start a new thread - to keep some thoughts in one place. But what to think about? Well, it seems the discussion is about: the document changed indication, and the status bar in general. STATUS BAR Let's start with the latter ... Sebastian named the thread LibreOffice status bar annoyances and he is somehow right. There are issues resulting from a very old and a driven by constraints design. For example, the little '*' is mainly caused by the need for a very compact symbol - here, please think in 480px width. Some more issues of the current design: * The indicators mix information and invisible actions (click, double-click for some surprise) * Information is shown by hiding it (document changed status, document signed status) * It misses charm with all its INSRT, BLK and STD (And, when the block selection has been introduced, the menu has been changed to introduce a bit more clutter, sigh.) * It looks very dated and cluttered Agreed? Concerning the dated look: The OOo guys reworked the status bar to remove some of the lines and boxes. Here is some discussion [1], and the issue [2]. Concerning the weird information representation: Within the discussions of the new zoom slider, I started to add ideas how to rework the status bar. Today, I would have done it a bit different, but maybe it's interesting for you to look at antique (3 years old) data :-) [3] You may notice, that the selection modes thing has been changed, and that all the items in the status bar got their own visual symbol to improve the representation. I also added no outline level (Keine Gliederungsebene) to teach the user what the slot is used for (today, it is empty). This might have helped to reduce the hazzles one could read today on the TDF discuss list [4]. Concerning the view selectors at the bottom: Some of you might not use it, but we should be careful to remove something which had been intentionally added by Microsoft some years ago. I'm sure they did some serious research ... especially when looking on our totally screwed UI that hides these options in the Zoom ... dialog (a side note: we do have a view menu). DOCUMENT CHANGED INDICATION I read all the comments very carefully and I understand some thoughts and concerns. However, the constraints / requirements do support Kohei's solution (if we want to keep the current save toolbar icon approach). A solution should: * just work * be unobtrusive (don't catch attention if it isn't required, don't waste space) * be self-explanatory (if possible) Concerning the latter, this is impossible with any approach. But to inform the user, the title bar totally misses any kind of tool tip or help text that explains its use(fulness). But the current solution isn't perfect, of course. Current issues: * The extended help tip still mentions the '*' for a changed document. * For unsaved documents, the normal tool tip mentions The document has not been modified since the last save. (Small issue, may not be changed). * The red ! is indeed a bit strange considering the importance of this message. * The icon does not communicate any behavioral difference - it is just a status information, but looks very similar to the view mode buttons etc. * The double-click behavior is inconsistent to all platforms I know of. It may even be problematic for some users ... personally, I would remove it. But how to address the issues you raised? My personal take: * Keep the status indicator where it is (in the status bar) * If the document is unmodified, add some very subtle document shape. Then, there is a reason for showing a tool tip and the What's that?! effect may be reduced. * For the modified document, reduce the warning level and - maybe - just show a document icon with a yellow star in it. This a) is similar to the old '*', and b) is used for to indicate new documents on certain platforms. And, just a small intentional idea - what about adding a bit more value to this feature. For example, add the Document is modified. Saved XXX minutes ago. time to the tool tip. If things go wrong, people tend to look at their data files to know how long they have been working on this document - so discarding any changes might
Re: [Libreoffice] Discuss quot; Easy_Hacks: Remove Sheet From Filequot; ?
Hi Regina, great catch! I really missed to have a look at the issue tracker, since I didn't expect the specification to happen there. I was wrong, but at least, it really was a Project Q activity ... Am Mittwoch, den 24.11.2010, 17:19 +0100 schrieb Regina Henschel: Hi Christoph, [..] But, I assume the reason for having the menu item is related to something I already referred to. I assume that the Insert Sheet... did feature the from file option since the beginning - but people did not find it (oversimplified, might have been a special request by one customer). So, another menu item has been added that rewarded people by just scanning through the menus ... The menu item has been introduced with http://www.openoffice.org/issues/show_bug.cgi?id=1834 (very long issue) My favorite quote is: You probably have no slightest idea about what your program is used for, what are typical use scenarios. Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Discuss quot; Easy_Hacks: Remove Sheet From Filequot; ?
Hi Kohei! Am Mittwoch, den 24.11.2010, 16:38 -0500 schrieb Kohei Yoshida: On Wed, 2010-11-24 at 17:19 +0100, Regina Henschel wrote: [...] I'm a bit puzzled. The original issue was that it was extremely mind-numbingly hard to open a text csv file from Calc from File - Open (which I wholeheartedly agree), and the solution was to add Sheet From File... menu item in the Insert menu!? Hmm.. Okay. ;-) irony It seems easy. If you cannot solve a certain problem, just provide a different solution. /irony ;-) Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
