[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Screenshots for 1.3, page layout


On Saturday, March 21, 2009 3:15 PM Chris Travers wrote:


On Sat, Mar 21, 2009 at 5:40 AM, John1 <..hidden..>
wrote:

I am planning to implement ledgersmb shortly so it was good to see
some screenshots of 1.3.

One thing that I think could be improved is the page layout. I think
it is important for the page to be laid out as well as possible. In
particular, I think it looks much better if input fields all line up
below each other. For example,

Contact screen:
http://ledgersmb.org/files/account.png

It would be much better if Customer Number, Starting Date, Credit
Limit and Discount fields all lined up below each other.

To achieve this, field names have to be chosen carefully so they are
of a similar length or if this is not possible then consider moving
the field to a different column.


How would this affect i18n/translation?  Given that strings are
re-used across many screens, are we creating a nightmare for
translators by doing this?
As yet, I know nothing about how localisation is implemented in Ledgersmb. Indeed, I know *nothing* about the structure of the ledgersmb code in general, so I apologise in advance that any suggestions I make are from this position of ignorance.
If you are concerned that say shortening "Customer number" to "Cust no" is going make it confusing for translators then perhaps you could consider having a field description for each field. This could either be a detailed description e.g. "Customer number is a unique reference number allocated to each customer account", and/or each field could have longname (Customer number) and shortname (Cust no). Then, the shortname or longname can be chosen for each screen independently depending on space available. 



e.g.

Cust No:
Start date:
Credit Limit
Discount:
Bus type:

These suggested field names are similar enough in length now to
allow for the input boxes to all be aligned below each other.


Through now, the issue with designing this screen has been to try to
make it so that any such changes can be made on an as-needed basis
using CSS and the like.  We have hence been working hard to try to
make sure we have properly done HTML which can be subject to better
CSS customization than before (which involved tables for layout).

The real tasks in order to make the UI better now involve a couple of
questions: 1)  How do we set up appropriate CSS file structures to do
this? 2)  Who is responsible for maintaining which CSS files?

There are some other useful CSS tricks as well that can now be done,
like hiding fields that a company doesn't use and the like.


Sounds useful


I guess I am going to propose language-specific CSS filles for now.
Handheld support is desirable, but at the moment, Pocket IE is not
supported.  Minimo works but I found it to be unstable.  I don't know
about mobile opera, and pocket IE can be supported by add-on
developers for their add-ons without a lot of work.
I wouldn't have thought that there would be that much demand for handheld support, but certainly worth laying the foundations for handheld support in the way that page structure is implemented. 



It may seem a bit pedantic but I think it will make a big difference
to the application if a lot of thought is put into page design and
layout. An aligned layout is easier on the eye, easier to read and
therefore quicker and more userfriendly to use.


I agree.  I also think that some of these issues are going to take a
major branch or two to really shake out.
I am no expert on page layout and certainly not css, but I suppose if the field names are put in one <div> and the input boxes in another <div> then css can be used to achieve alignment of the input boxes. As long the need to align input fields is being considered when designing new page structures then that's fine. It's good to know that a lot of thought is being put into a clean and flexible page structure. I appreciate it may take a major branch or two to really sort out.