[Tsheetx-developers] Fwd: txsheet-2.0-demo: new commit for internationalization

[Scott M. <sco...@gm...>]

---------- Forwarded message ----------
From: Scott Miller <sco...@gm...>
Date: Wed, Apr 13, 2011 at 1:45 PM
Subject: Re: [Tsheetx-developers] txsheet-2.0-demo: new commit for
internationalization
To: Mark Wrightson <ma...@rw...>


Ah, I was not thinking about "mobile devices", so I saw no point in
stretching things vertically.

We could perhaps make two layouts, one for normal screens and another for
mobile devices, is there an easy way to tell if a mobile device is viewing
the page?

The current version uses a 'text' field in the database which can hold up to
65535 characters, ie. 64kb.  I'm fairly certain (but haven't verified) there
is nothing in the code that cares how long a text message is, but it could
be affected by the php max_post_size limitation.

-Scott


On Tue, Apr 12, 2011 at 10:26 PM, Mark Wrightson
<ma...@rw...>wrote:

>  The way the current clocking form is, it is suitable for use on small
> screens i.e. a smart phone which is a good feature.
> The simple.php doesn't work well on a small screen due to width.  Extended
> descriptions with carriage returns aren't possible either in simple.php
> whereas the other clocking methods allowed for carriage returns due to the
> use of textareas instead of single row fields.
>
> I feel there is no need to cramp stuff up when there is no real
> requirement.  Simple.php needs to be all on single lines and that is fine,
> but for normal clocking I can't see a reason why it needs to be so
> slimline.  If you take google calendars for example (see attached),
> everything is nicely spread out.
>
> Maybe the message box restriction was in an old version of tsheetx
> v1.2/v1.3
> I suppose you could set a limit but if we do then it should be at least
> 1000chars, but then if there is no db limit then why bother?
>
>
>
> Regards
>
> Mark
>
> _____________________________________________
>
> Mob:  07725 695178
> Email: ma...@rw...
>
>
> On 12/04/2011 18:42, Scott Miller wrote:
>
> That was just an example, the sizes were very rough and adjustable.
> Considering we now get 7 days of information on one line of the simple form,
> I don't think we're so tight on space that we need to move to 3-5 lines for
> each item on the daily page.  I'd like to limit it to no more than two, the
> simple form does currently have this as an option (long description).
>
> I can see adding a date field is needed, and with the new form I would like
> to remove the clocking box altogether for this form.  I am in agreement that
> the message box should be restricted, but I don't believe there is a limit
> of 255 characters in either the code or the database, so I'm curious as to
> why longer messages are currently truncated?
>
> As for editing, I'm proposing you can edit multiple items at a time with
> the form, so there would be no need for an "edit" link, but yes the 'x'
> would be to delete the item. With a test user/test install, maybe play with
> the simple form a bit to get a better idea of how the new daily form might
> work?
>
> -Scott
>
> On Tue, Apr 12, 2011 at 5:18 PM, Mark Wrightson <ma...@rw...>wrote:
>
>>  There are lots of inherent problems with using the simple timesheet in
>> conjunction with other forms of time entry that I have always just disabled
>> the simple view.
>>
>> I think for the daily view, more than one clock on/off isn't really
>> required.  The more elongated layout could cause issues as there won't be
>> much room for the drop down menus if there is long strings, and the
>> description being so small i don't think would work.
>>
>> A hybrid could work however? - Maybe:
>>
>>   Client:
>>  [drop down]
>>  Message:
>>  [Message Box]
>>   Project: [drop down]
>>   Task: [drop down]
>>   Clock On:
>>  [12-4-2011 ]      [8.00 AM]
>>  Clock off:
>>  [12-4-2011 ]      [5.00 PM]
>>  [Clock on and/or off]
>>
>>
>>
>>
>>
>> Then rather than have the clocking box always visible at the top we could
>> use a bit of javascript to make it appear - slide in from behind the menu
>> for instance?
>> One of the most annoying things i found was it took much longer to enter
>> times than spanned a day boundary.  If the dates are already in this form
>> but preset to today's date, that would give users the opportunity to clock
>> over day boundaries.  The other thing that I found is that there should be
>> validation on the message box to restrict it to 255 chars or change the db
>> so this limit is removed as I sometimes entered rather long messages only to
>> find that it was truncated at a later date.
>>
>> If you wanted to add lots of times could you do it as follows:
>> Use my form as the entry method then have a button that you could click to
>> add another clocking.  The form above is then cleared and the data you
>> previously entered is summarised as per Scott's image above it.  the cross
>> could be used to delete the time and another icon next to the cross could be
>> added to edit the stored info.  You would then need a final save btn:
>>
>> Maybe:
>>
>>   Client1
>>  Project1
>>  Task 1
>>  Description
>>  Times
>>  edit/delete
>>   Client 2
>>  Project2
>>  Task 2
>>  Description 2
>>  Times
>>  edit/delete
>>
>>
>>
>>
>>
>>   Client:
>>  [drop down]
>>  Message:
>>
>>  [Message Box]
>>   Project: [drop down]
>>   Task: [drop down]
>>   Clock On:
>>  [12-4-2011 ]      [8.00 AM]
>>   Clock off: [12-4-2011 ]      [5.00 PM]
>>  Add another clock
>>  Submit All!
>>
>>
>> Cheers
>>
>> Mark
>>
>> _____________________________________________
>>
>> Mob:  07725 695178
>> Email: ma...@rw...
>>
>>
>>