User:Mipmap

About me
A person who likes UI design. Not very good programmer but know a litte bit about javascript and such. In the long term I would like to take part in coding, but for now I will only do wireframes. I'm a bit sloppy but have a lot of ideas.

Documents for self and community management

 * [[Media:Design document template - landscape a4.svg|Design document template - landscape a4.svg]]
 * [[Media:Design document template - portrait a4.svg|Design document template - portrait a4.svg]]
 * [[Media:LibreOffice Color Swatch.svg|Libre office color swatch.svg]]

Documents with design proposals

 * [[Media:New icons for colorizaion.svg|Toolbar icons for color picking (characters, paragraph)]]
 * [[Media:Features icons.svg|Icons for Version 4 Feature webpage]]
 * [[Media:New Color definer.svg|Color wheel]]
 * [[Media:New Color picker.svg]]

Links to "creative pages"

 * Crazy ideas page - mainly developers
 * Whiteboards - mainly UI people
 * Blueprints - ideas marked as pending to be coded.
 * Archive - for built and discarded UI features, as well as pending to be coded.
 * Proposals for icons - they are settled, but still fun for the eye.
 * Branding and marketing ideas
 * Visual Elements - Stuff which the design and marketing departments have agreed on is ok.
 * Mockup Kits - resources for those who wants to edit toolbars etc.
 * github.com/libodesign/tango-testing|Default icons used in LibreOffice
 * Dialog conversion rules Dialogs are being converted into GTK+ and here is the instructions.
 * Missing features for the enterprise user
 * Various UI improvements

Extention production using Python & Uno
I'm studying how to make extentions for LibreOffice and thought I should document my progress. I'm using windows 7 with LibreOffice 4.0.4.2 installed.

Background
LibreOffice is delivered with Python. It lives in the LibreOffice4.0\Program folder. The python scripts you write should be placed in this folder.
 * UNO = ?

Getting started
In order to run external scripts you need to poke a hole into the LibreOffice program so that your external program interact with the documents and features you have opened in LibreOffice. This is done by starting LibreOffice with a "flag". This can only be done in a commmand terminal. The terminal will also be used to launch your python scripts (at least initially).
 * 1) Open windows powershell. It's a bluish terminal.
 * 2) Navigate to the installation folder for libreoffice, which usually is in Program (86) folder. Then navigate to the folder program in here. The full path would be 'c:\Program (86)\LibreOffice4.0\program\' this is done by typing cd to enter a folder and cd .. to walk up in the hierachy.
 * 3) Make sure LibreOffice4.0 is turned off. This includes the quicklauncher in the notification center.
 * 4) Launch LibreOffice by entering .\soffice "--accept=socket,host=localhost,port=2002;urp;". The name "soffice" is the legacy name for LibreOffice, which was StarOffice (later OpenOffice). The rest of the code tells the program to open a channel and listen to commands from a certain direction. The .\ in the beginning is a terminal command to launch a program. When you press enter LibreOffice will launch into its primary screen with all the available apps. You cant copy paste into the termina with keys. Instead, to paste something you simply select some text somewhere and then righclick with mouse to paste it.
 * 5) Launch a pythonscript (like the ones below) by typing .\python filename.py Again, .\ will launch the python program. The filename mentioned is the name of the file you would like to launch. Usually this command would be something like '''.\python example_1.py".

Potential error messages: ???

Tutorials i have found
Python bridge to UNO

Moodbridge
Designers loath both MS Office and LibreOffice suits because of their limited design tools. The new MS products can handle application of style better with their new ribbons system. LibreOffice is behind in this area. Reworking the entire UI is out of scope. I suggest creating an import tool that can read a svg files content and translate it into Template files and styles. A designer can then create templates in Illustrator or inkscape without ever touching LibreOffice.

How it would work
Designers work a lot with moodboards. Its a paper on a wall where they stick things they find inspiring – color themes, typefaces, pictures. What if you could use such a moodboard as data container for a template directly? So, the designer creates a moodboard in a vector editing software – such as inkscape or Adobe Illustrator. In this page various features typical office design elements would be defined: page types (left, right, firstpage, margins, paper size), slide layouts, shape styles, clip art contents, special images, fonts (can be included), typographic rules (headers, web-links), tables, equations, diagrams, etc. You would then save it as a svg. This svg would be imported into LibreOffice using a a proposed Moodbridge feature. The elements in the SVG were given very specific id:s. This would be done either by hand or by some extention to the vector software. The easy way is to use a moodbrige template made by skilled programmers. The Moodbridge tool in LibreOffice would try to find these ids, interpret the format of the contents/children and rebuild it into a liberoffice template file (for writer, impress or whatever). The user would now have a beautiful template created by a skilled designer who does not even have to open the LibreOffice suit once without the designer touching LibreOffice.



Some initial thoughts about this idea

 * The strength of the LibreOffice developer community is the strong export/import features and the deep knowledge developers have in this area. An example is the PDF exports which trumps the Office suit. This fits the solution, since it will be a very advanced import feature for styling.
 * The main weakness of LibreOffice suit is how it looks – both application wise and the stuff you produce. There has been much criticism about this, but the solutions so far have been “total workover”. That is out of scope. This solution would solve one part of the problem: creating a work environment which enables creation of beautiful designs.
 * To edit/create good looking graphics you need very crisp tools. Programmers laugh at this but an ugly toolbar can be a reason for a sensitive designer to uninstall the whole thing. GTK tools and widgets are generally quite clumpsy and disturbing. By design you can not control these aspects since the GTK+ widgets will render slightly different on different platforms.
 * LibreOffice is excellent when you want to apply a style (select+doubleclick in list), but performs poorly while formatting them. You have to open a style menu and tweak a value, close and see how it looks. In a more powerful tool you can see the entire result directly.
 * A moodbridge tool could be created without changing any UI in LibreOffice (less work).
 * Vector editing software is optimized for design and layout. Office software merely supports it with very rudimentary features.
 * It is not possible to review templates of the entire suit at once. A use case where you want to create a branded writer template and a branded impress presentation at once is not well supported.
 * The word “Moodbridge” is not used by any other vendor in the office/desktop/applications area.
 * It would speed up the creation of typesetting/commenting on design/smartart/clipart/
 * The solution would be a cross application design tool without reviewing any existing code.
 * The LibreOffice community would be able to dip into the vast design skills of the Adobe user community.
 * SVGs can be created and edited online – perfect for web apps.
 * Everyone can do what they like to do best: programmers write export functions between xml formats, designers make moodboards and pick fonts/images, UI designers decide where to put the buttons on the Moodboard interface.

Mockups
File:Moodboard_example.svg example moodbridge ready moodboard. The page size is cropping the view so load it into an editor to see the whole thing. This moodboard document would define rules for a first-, left-, right- and lastpage, two slidetypes, one setup of headers, a diagram style and a image (border and margins). Pay extra attention to the titles which you can find in the svg xml markup code. It would be tags like these which the importer would be able to recognize and store in the template.

Further resources

 * Indesign to word and back – example of how you can import and export styles between indesign and ms word.
 * Moodboard by some designer - example of moodboard
 * [[Media:List of all formats.ods|A list of all formats which the svg styles and formatting would map to.]]

Icon Manager
There are 13000 icons in the LibreOffice suit, if you include all the themes which it gets shipped with. It way too much to edit one-by-one. If a flat iconset is added to it, the 13000 will grow to 16000. This will continue for each theme which is created. Actually this is a imaginary problem right now since editing the icons is such a daunting task.

My goal
I started hacking on a Icon Manager. Its main features are:
 * 1) Discovery: quick navigation of icons across folders. No more folder-opening! It should be as quick as selecting a item in a dropdown.
 * 2) Tagging: in order to group all icons which contains a folder as a backdrop (or some other generic shape) the icons should be taggable.
 * 3) SourceCode Inspection: it should be easy to find out where an icon is used in the sourcecode. This is particularly important
 * 4) Speedy loading: I don't want to wait for some program to open.
 * 5) Batch editing: I want to be able to download all folder style icons and edit them at once, then upload them and let the server "put them in place".
 * 6) Separation of colors and shape: SVG:s contain vector data and color. The colors should be stored as variables and when the user wants to retheme the iconset all they should have to do is to change some preset colors in a colortable. You can't do this with PNG:s.

Development diary
I created a database for the most rudimentary parts: icons, tags, filepaths and image data. A problem I had was that storing the images as individual files generated a huge amount of HTTP requests. Viewing all icons at once generated 13 000 HTTP requests. To solve this I converted all images into base64 strings and stored those. These are retrieved in a gigantic (1-2MB) json object. It's quite snappy (running as localhost) and only requires _one_ HTTP request.

I have already discovered several very bad icons. Some of the LibO branded icons don't have transparent backgrounds.

Next step is to create an icon-inspector. I'm halfway through, but could really need some input from a icon-designer.


 * [[File:LibreOffice Icon Tagging Project.ods]]

Template for design proposals
I have been sifting through design proposals for a while and I think it could be a good idea to have a template for design proposals in svg. Right now they are a mishmash of icons and text. These are my templates:
 * [[Media:Design document template - landscape a4.svg|Design document template - landscape a4.svg]]
 * [[Media:Design document template - portrait a4.svg|Design document template - portrait a4.svg]]

Icons for the Features page
On request I made some icons for the |Features of version 4.0 page.
 * A SVG version: [[Media:Features Icons.svg|A document where all proposed icons are listed]]. Feel free to give feedback through the mailing list.

Liberation wiki icon with text
The current icon does not explain that you are in the wiki. Added some text for better readability.



Color palette
The marketing team put up a list of colors. I have used them to create a palette. Here is one implementation. Observation: A color picker should have some default themes nicely ordered into columns or rows, with a thin border around them. This will prevent any "gray shadows" to appear in the intersections between the tiles.


 * New color picker.png
 * [[Media:New Color picker.svg]]
 * Colorpicker in development.png
 * [[Media: Colopicker version 2.zip|the latest version of the picker]] made with glade and python

Color wheel
A color definer which is opened when you press the plus buttons.




 * A hue picker should not be mathematically correct since some colors are weakert (turquise and yellow) then others (blur, red). The weak hues should be given slightly more room then the others to make them easier to pick.
 * The color sample is placed in a square with a gray border. The border color should such that it is minimally visible. This means that it will be visible even tough the fill is white, but not darker - as it might interfere with some colors.
 * The colors can be fed into the system by text, either as comma/space separated rgb values or hex. The rgb values have these little arrows next to it. The reasono for having rgb in one field is to make it easier to copy/paste the color.
 * The wheel is better then squares because its prettier! It contains color hues mapped toward white. The Mapping of hue to black is done in the slider. It is of course possible to reverse these but that result is ugly! Same thing for having both in one window.
 * The markers are round icons which are filled with the selected colors.
 * This setup opens up for theme constructing in the future (where you control the theme by angles etc. like many professional tools do today).
 * This version is fully contstructed in Inkscape where 8 base colors have been blended into each other and then a white fading circle is placed on top. A cut out has been placed over it to create sharp edges. It is available as a svg document if you are interested.
 * The markers have a black to white gradient border so that it is visible in all hues.

My blogposts about color-pickers
See this (swedish) blog (its mine) for more references on color pickers.
 * | Part 1 - introduction
 * | Part 2 - os standard pickers
 * | Part 3 - installed software
 * | Part 4 - dedicated web tools
 * | Part 5 - web tools built in pickers
 * | Part 6 - phones and tablets
 * | Part 7 - summary
 * | Part 8 - discussion

Color picking buttons
The color picking is being reworked. Perhaps the icons could use some love too. The icons are filled with the current selected color. The borders have a gradient. The gradient in the sketch is black to white, but it makes it hard to read. Perhaps it should be dark gray to light gray, instead of black to white.



Development materials: [[Media:New icons for colorizaion.svg|SVG document with icons]].

UI workover: scalable and touch friendly LibreOffice
I made some experiments in UX design and tried to address the new needs a touch interface would require. Also, I'm in love zenware since it relieves my work memory and gives a lightweight feel.

This was my draft which I built in glade on windows:



This is a small window with the panel pulled down.

It would keep much of the current layout but with some additions:


 * The toolbars would be organized into four columns and stacked on top of each other.
 * The tool categories should be Document, Navigation, Format, Tools.
 * Icon sizes would be supported from the tiny 16px sizes of today up to 1-1.5cm buttons. This would require a rework of icons of course.
 * Overflow results in a "arrow" decorated button. When pressing it you can either get a list (desktop) or a pop-up with a icon/toolbar-grid (touch devices).
 * Tools are stacked in order with the most important in the bottom. This will relieve work-memory.
 * To access more tools, you drag the toolbar down. On desktop you press ctrl-up/ctrl-down to move it around. Or drag it with the mouse. In here you have all the buttons in columns. Some columns are more populated then others and will thus be higher, but that's ok.
 * In a extreme case, you can fill the entire screen with toolbar-button This would be bad on desktop but really capability on tablets where you don't have the menus to stuff with tools.
 * The columns would help guide the user since they function like "stops" for the eyes.
 * You would be able to hide the toolbar entirely, with only a thin row and a knob as a marker. This is good for "reading mode" and when you are working on a small screen like a phone.

I built this in glade so if someone is interested I can upload it somewhere.

Old Idea which is bad
Currently tools are organized in a left-to-right flow system where all buttons are given equal importance and size. I find this hard to navigate.

To organize the toolbar and to give new users an idea of the features which are available, I suggest adding a row with "Tool Tabs". They function in a similar way to ribbons, but are less cluttered. The MS ribbons are good in the sense that they give the opportunity to squeese a very large number of settings into the panel. A problem with this is that it looks cluttered and it is hard for the eye to read the entire panel from left to right.

I suggest adding a simplified version of this system, where you simply group tools into tabs and keep the little rows of icons which are used today as they are. Here is a wireframe:



The new user would have large square buttons as tabs, with nice icons and perhaps a small line of text under them. The more experienced users can work in the miniaturized form or even display them "inline" where the "Tool Tabs" are stored in a drop-down menu on left/righthandside of the panel. My initial plan is to select the tabs with Alt+Numkey. Alt+1 would open the first tab (Document).

Positive aspects
 * The interface gets an overhaul without breaking the current paradigm: rows of small icons and input fields.
 * Users can explore features by clicking on the big buttons.
 * The layout is easy to understand and implementation is hard to fail with since its just left-to-right flow of buttons (or right to left if you are arabic).
 * It would work in all applications.
 * Instead of having an upper and a lower list of buttons (like impress) you would have one row at the top. It would make the interface more consistent.
 * You can have all sorts of things in these button-rows.
 * It is easy for extention constructors to create a "large" tab icon under which he/she can group the specific buttons.
 * More buttons can be added for each tool-subgroup. Instead of just having "Bullet list" or "numbered list" you can have style options directly in the menu.

Negative aspects
 * The user is required an extra click every time they want to edit in a different way. Working with paragraph styling and then switching to table editing would first require a buttonpress on the large button. If the dropdown is used then an additional button would have to be pressed (open dropdown - select tab).

Format and Style management
The current setup of buttons, menus and panels can very easily break style rules, since a user may first apply a style and then quick-edit it from the panel. There are also two different types of windows for formatting: (1) the formatting window which you access from the Format dropdown menu, (2) the window which opens when you choose to edit a style in the sidepanel.

My suggestion for managing styles and formats
Split current toolbar into "Quick format" for easy hardcoding and "Style format" for style picking. Splitting them will decrease risk of blending hardcoded formats with styles. Also, I suggest a removal of the side panel with formats. Even though it is easy to use it has too much content crammed into a small area. I suggest moving these panels into dropdown menus (like paragraph is today). Last and perhaps most important, I suggest creating a new master window for format editing. This window should give users all the settings available in terms of styling.

The user may now work with quick formatting by pressing the bold, italic and other buttons like they always have. These formats are not stored in a style. If the user wants to work more seriously with a longer document then the style toolbar panel is needed. In this panel the user can apply Page, Paragraph, Character, List and Frame styles by selecting them from a dropdowns. If the user wants to change the entire stylesheet of the entire document - it can pick one from the Template dropdown. If the user wants to edit the dropdown contents they have to press the Edit Styles buttons. This will open up the following window:

New style (and format) window


This window will contain all styles currently in use in this document. The right panel contains the different groups of styles: Page, Paragraph, Character, List and Frame. By pressing one of these a hierachical list of styles emerges. The hierachical part is to make it easy to understand how formats are inheriting from each other. The top panel contains a preview of the style which is being edited right now. This changes as you select and edit different styles. It is locked on top and will not move around as you scale the window. The bottom right panel contains all the settings. The layout is as follows: So, when you edit the style you simply scroll upp and down here and make the edits you want. When working with Quick-formatting you don't have any style hierachy, just the current style in use.
 * Each category has a title, so that you can read them quickly to navigate. In the current version you do this by pressing tabs. The tabs can be so many that they start to move around. I like scrolling more. The categories are divided by light/dark background (no borders) to make it easier on the eye.
 * The content of the settings is divided into three "columns". The first one is a narrow column, usually containing a checkbox which determines if the style rule should be used at all ("Use uppercase"). The other two columns contains settings. Each setting has a title. Sometimes this is stupid, but I think it is more important to be consistent.

Default template
To organize the work of improving the default template across the suit, I wrote down all the styles which comes hardcoded with the install:
 * [[Media:List of all formats.ods|List of all formats]]
 * [[Media:Test document.odt|Test document]] Lorem Ipsum document for testing how fonts and styles work together.