Re: [Tsheetx-developers] 2.0 demo feedback

[David T. <tom...@us...>]

Guys, try to keep your exchanges on the developer-list (that means checking the addressing when you reply).
That way there is a (searchable) record for everyone to see what is going on.
 
Critisism should be nothing personal (hard on the product, but soft on the person), in that way it can only make the software better.
Cheers  
 


Date: Sat, 12 Feb 2011 19:45:43 +1100
From: pal...@gm...
To: sco...@gm...
CC: ma...@rw...; tom...@us...
Subject: [SPAM] Re: 2.0 demo feedback


Scott,
I agree also with this issue. I think it can be solved by continuing in the direction we are going. That is, to have minimal html structures and minimal html tables, and to use css includes to do all the formatting. I am not a css expert. In fact I would rate my css skills at below beginner. However the book I am reading, "CSS The Definitive Guide" by Eric Meyer (O'Reilly) has numerous examples where the styles are set up to allow expansion and contraction of table cells etc. So I have confidence we can fix the problem you raise.

The next phase of the presentation is now to devise and test css styles to consistently format the monthly, daily, weekly and simple time entry tables. But that will take some time to organise. 

I would also like to "modernise" the menu system into a set of tabs, or maybe a hierarchical directory tree on the left.

Finally, I'm soon to take off on a trip to colder places late this month and next, returning around 17 March.

Ciao
Peter

On 12/02/11 07:51, Scott Miller wrote: 
(finally changed the subject)

Another complaint:  We need the site to be able to (mostly) fill a browser window.  I have a large screen, and it irritates the begeezers out of me when I have a site that can only fill a small portion of my available screen.  This is especially important for the simple timesheet where you have a potentially lengthy description field that suddenly becomes nearly unusable because the space available is tiny.  Configurations, user mgmt, reports, all these need the ability to expand horizontally when they can.  This may not be as important for all areas, but I think it would be bad form to allow variable pages only in a few areas...

-Scott



On Fri, Feb 11, 2011 at 8:24 PM, Scott Miller <sco...@gm...> wrote:

Hey guys,

Ok, admittedly, I'm not an OO guru.  But, could you please explain why the table name class has been created in the way that it has?  In particular, I'm totally failing to see how the many tiny routines to set and return the private variables is a good idea.  Why not declare the variables public, and allow the other routines to access the table class variables directly?  And we could have the class itself, read an appropriate .ini file to load the variables in the first place, rather than just including it as a php file as is currently done.

Now if there were reasons to protect the members of the class, perhaps some of this is needed for the authentication piece, but I honestly can't come up with a good reason that most of the classes' variables couldn't be public.

-Scott 




On Fri, Feb 11, 2011 at 7:38 PM, Scott Miller <sco...@gm...> wrote:

Hey Peter, Mark,

I just downloaded (checked out via svn) the 2.0-demo branch.  I haven't played with it a lot, but for the most part it looks good.

I do have to complain about the new date navigation.  It looks ok, but it's a pain to use.  I now have between 5 and 10 clicks of the mouse to change the date. That is, in my opinion, way too many; so I think that whole piece needs to be rethought.

I'm going to go check out some of the code changes now, and maybe see if I can't add the new configuration stuff into your 2.0-demo...

-Scott