Hi!
I really like the look of the grid at http://cordova.apache.org. I mean this (wow, tiles work on this forum):




Apple's Xcode grid isn't bad too.

So the open job is: propose a grid design that would replace that one in Kexi forms, Kexi reports (http://kexi-project.org/pics/blog/docth ... design.png) and possibly any other KDE app that needs it.

It would be also nice to have:
1. a visual (and interaction?) design of how guidelines appear when you align insert or objects, it's this kind of activity: https://www.youtube.com/watch?feature=p ... wvyM#t=453
2. resize markers and the frame (see the blue dots and the frame for objects at https://www.apple.com/iwork-for-icloud/ ... aphics.jpg). Maybe it's nice if it kind of borrows the focus/active color of the current UI style. Currently we have no standardization for this in KDE or even in Calligra (http://www.calligra-suite.org/wp-conten ... 619836.png).

Wow, UX guidelines for the guidelines!

I understand this is just beginning and not a precise or complete list of requirements.

Hello,

Below are some thoughts about grids in general. Interaction with rulers, object selection, resizing, etc can come later.
Even if it's redacted as affirmations, what follows is my opinion.

What is a grid for ? They are used primarily for two purposes :

• Align things properly : one often needs to have rows/columns of elements
• Measure (horizontal and vertical) lengths : margins, widths, heights

I couldn't find more. For each of the two items above, there is a more powerful alternative, but grids are easier to use/discover, even if harder to implement well.

Measure
The program needs to think from the user point of view. That is, when the users pixel-perfectly aligns the left side an item with the 1cm rule, the program should have the x coordinate at exactly 1cm, not 1.01 or so. The rule must not be drawn approximately, because then the user would have no way of knowing where it is.

Subdivisions
Good grids are given by graph paper. Graph paper usually has four types of lines : thick lines every 50mm, normal lines every 10mm, thin lines every 5mm and very thin lines every 1mm. This pattern seems to work well. Counting to 2 is something the eye can do easily, and it's the maximum distance a line will ever be from a thicker one.
Screens usually have a lower resolution than printers. Trying to put a line every 1mm on a screen would be difficult. Xcode uses a 20mm base grid, then a 10mm secondary grid and a 2mm tertiary grid. It works well, but I would like having a 40 or 50mm grid too.
I feel Cordova's grid lacks subdivisions : there are 15 lines between two crosses. It is by far the best-looking on-screen grid I've seen, however.

Units
The unit the grid uses is relevant. For the lambda user, the unit system the user has set in System Settings should be used. Power users like programmers may get a pixel-based grid depending on the situation (because Qt still uses pixels in many places).

Zooming
The grid should remain consistent with itself : thick* lines must not jump from one place to another. Thinnest lines should disappear when zooming out, and new lines should appear between them when zooming in.
* "thick line" here refers to major subdivisions. It doesn't imply a particular visual design.

Layouts managers
I think grids are irrelevant when layouts managers are used to arrange content. Qt Designer hurts me by displaying a grid where I have no use of it -- the layout manager does everything !

Show/hide
There should always be a way to quickly hide the grid (a menu item is fast enough, while an option in the configuration dialog is too slow). This is for previewing and for people who don't want/need to use a grid.

Snapping
For snapping we have several possibilities :

1. Enable snapping by default when the grid is shown. Because the grid is there to be used, isn't it ?
2. Enable snapping when the grid is enabled. Because if the user decides to see the grid, s.he is going to use it.
3. Never enable snapping. Let the user choose.
4. Remember whether the user enabled snapping last time s.he enabled the grid, and restore the setting.

Snapping should never be enabled by default when the grid is not shown. Whether turning it on should be allowed is to be discussed. I don't see any good reason to disable it, besides it may be confusing if enabled by accident.

Waiting for feedback !

Louis

Thanks a lot, Louis. That's more that I expected!
I'll use these analysis in my work.