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

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

Hey Mark,

I have a 22" at 1680x1050, and I have a single browser window taking up
about 4/5ths of that, so, yeah, I like having lots of width.  I would argue
that having any space at all for the description makes it usable, but I
understand not everyone likes stuffing everything in one line, that's why
the big description field was created (I didn't create that by the way, but
I did keep it around :-)

Can you check your changes to the simple form in?  I'm using that to create
a rough example of what my vision for a new daily form. And please don't
panic yet, I'm trying to make the daily form better, and together I think we
can do that such that both of us, and therefore our myriad users, are happy.

-Scott

On Wed, Apr 13, 2011 at 3:42 PM, Mark Wrightson <ma...@rw...>wrote:

>  Hi Scott,
>
> I think it is a bit much effort to make a mobile version of the site.  The
> stretching things width wise isn't just a problem for mobiles.  Just
> consider ipads, it could an issue there.  Also take my example, I use a 24"
> widescreen monitor (1920x1080) so often have two browsers open each taking
> up half of the screen.  Therefore each webpage has 960pixels width.  If you
> look at the simple timesheet with that width, it is near enough un-useable.
> I can get a total of 14 characters in the description box before it has to
> overflow.
>
> Why do we need to make things so thin and wide?  The current clocking box
> is already in quite a good format in my opinion.
> Yes it needs an update so that dates can be entered and times are done in
> text fields rather drop down menus, but the layout is not cramped and it is
> clean.
>
> The simple timesheet could be improved quite a bit by simply putting the
> description field below the drop down menu fields.
> There is plenty of space in the second row.  I have just spent some time
> looking at simple.php and i have gone through and done all the xhtml error
> corrections. (from 125 errors to 6)  The 6 errors relate to the drop down
> select boxes that are populated by javascript. I have also tweaked the
> layout type "big work description field".  Please go into your config table
> and change simpleTimsheetLayout field to "big work description field".  I
> feel this style of layout is better than the single line version as it shows
> much more information whilst using only slightly more vertical room.  it
> also means that it is useable on a 960pixel width screen.
>
> I think if you really want to add a new way of clocking in like simple.php
> but for proper clock on/off then it should be a separate page to the
> clocking on/off for daily.  Being able to make several clockings at once in
> detail may have its purpose but shouldn't be confused with single clockings
> on a day to day basis.
>
> Can we keep the daily clocking roughly how it is but maybe add a completely
> separate page for multiple clocks?
>
>
> Regards
> Mark
>
> _____________________________________________
>
> Mob:  07725 695178
> Email: ma...@rw...
>
>
> On 13/04/2011 14:45, Scott Miller wrote:
>
> 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...
>>>
>>>
>>>   On 12/04/2011 17:11, Scott Miller wrote:
>>>
>>> Ok, so, I'm thinking about redesigning the daily time entry form(s).
>>> Several months ago someone (may have been you, Mark) asked about changing
>>> the simple form to have people record starting and ending times, and I
>>> vehemently disagree with doing that, but, remembering that got me thinking
>>> that perhaps the daily form should look more like the simple form.
>>>
>>> The vision I currently have is something like the attached image, where
>>> you have the client/project/task  description, then some radio buttons to
>>> clock on and off now, as well as time start/stop entry areas.  We could then
>>> remove the whole "pop up" dialog thing currently at the top of the page.
>>>
>>> How does this sound?  can we improve this form even more?
>>>
>>> -Scott
>>>
>>> On Tue, Apr 12, 2011 at 2:48 PM, Scott Miller <sco...@gm...>wrote:
>>>
>>>> Hey Mark,
>>>>
>>>> I'm going to add my answers to the middle of your text below:
>>>>
>>>>  On Mon, Apr 11, 2011 at 10:50 PM, Mark Wrightson <
>>>> ma...@rw...> wrote:
>>>>
>>>>>  Ah ok fair enough.  Just wondering - do you think it would be a good
>>>>> idea to get all the forms working again and get to a point where we know the
>>>>> core functionality works again before we do much more redesigning??
>>>>>
>>>>
>>>>  I think it depends on the situation.  If we want to redesign
>>>> something, now's the time to do it, so why waste time fixing some area that
>>>> you're planning to completely redo?  If you're not planning to redo an area,
>>>> then, yes, getting those forms to work again would be working toward the end
>>>> goal :-)
>>>>
>>>>>
>>>>> I'm not going to be able to do very much atall over the next couple of
>>>>> months as it is "all hands on deck" to get my disertation done.  On another
>>>>> note I have pretty much completed a upgrade system.  It does the following
>>>>> interactively:
>>>>>
>>>>> 1. backup of db
>>>>> 2.checks for any prerequisites
>>>>> 3. performs db updates
>>>>> 4. complete
>>>>>
>>>>> The only problem I currently have is that it works fantastically when
>>>>> moving from version v1.5.3 to v1.5.4  or even v1.5.3 to v1.6.0 as long as it
>>>>> is a single jump.  I can't currently handle: v1.5.3 to v1.5.4 to v1.6.0.
>>>>>
>>>>> an upgrade basically consists of a new class file called for example:
>>>>> upgradev1_5_3_to_v1_5_4.class.php
>>>>> so another file could be created i.e.
>>>>> upgradev1_5_3_to_v1_6_0.class.php in which case only a single upgrade
>>>>> step
>>>>> is required and that will work fine (but starts to get labour intensive
>>>>> creating files for every permutation).
>>>>>
>>>>> I've written a script that can work out the necessary upgrade path i.e.
>>>>>
>>>>> going from v1.5.3 to v1.6.0
>>>>> run the following upgrades:
>>>>> upgradev1_5_3_to_v1_5_4.class.php
>>>>> upgradev1_5_4_to_v1_6_0.class.php
>>>>>
>>>>> But this is the point where I stopped as I was slightly concerned that
>>>>> if the database version is 1.5.3 and the code version is 1.6.0 and the code
>>>>> base had changed significantly in 1.6.0 there is then a possibility some of
>>>>> the code in the class file "upgradev1_5_3_to_v1_5_4.class.php" would no
>>>>> longer work correctly.
>>>>>
>>>>> Have you got any thoughts on this problem?
>>>>>
>>>>
>>>>  Running each step is the way to go.  Modifying the database, since we
>>>> shouldn't be looking to the databases for much more than the version number
>>>> during the upgrade, it shouldn't ever matter what information is in the
>>>> database while moving from one version through however many upgrade files as
>>>> needed to get to what the current database schema should look like.  As long
>>>> as each step is valid, you should be able to go through all the steps.  This
>>>> is how the upgrade process has worked in the past.
>>>>
>>>> Although it is tempting to write upgrade scripts that are able to jump
>>>> from a past version directly to the new version, this is not recommended
>>>> because, as you've discovered it makes loads more work for future upgrades.
>>>>
>>>> The upgrade should not attempt to figure out what code files need to be
>>>> changed/added/deleted.  The upgrade process should look like this:
>>>>
>>>> 1. Old installation with old database
>>>> 2. download new version
>>>> 3. unpack the new version
>>>> 4. rename the old version's directory something different:  tsx ->
>>>> tsx.old  or use version numbers or whatever
>>>> 5. move the new unpacked version to the original directory's name
>>>> 6. optionally copy a configuration file or two from the old system to
>>>> the new system to assist with the upgrade
>>>> 6. open a web browser to the site
>>>>
>>>> In this way, the new version should be a completely clean upgrade, so
>>>> the only work that needs to be accomplished is the upgrading of the
>>>> database.
>>>>
>>>>    Cheers
>>>>>
>>>>> Mark
>>>>>
>>>>> _____________________________________________
>>>>>
>>>>> Mob:  07725 695178
>>>>> Email: ma...@rw...
>>>>>
>>>>>
>>>>>   On 11/04/2011 23:33, Scott Miller wrote:
>>>>>
>>>>> I had managed to wrap my brain around most of it last Friday, but I
>>>>> didn't get a chance to mess with it today.
>>>>>
>>>>> I'm actually toying with totally redesigning the daily form, I'll try
>>>>> to email you tomorrow detailing some ideas I had to redesign it, and we can
>>>>> bat it back and forth.
>>>>>
>>>>> -Scott
>>>>>
>>>>> On Mon, Apr 11, 2011 at 10:30 PM, Mark Wrightson <
>>>>> ma...@rw...> wrote:
>>>>>
>>>>>>  Hi Scott,
>>>>>>
>>>>>> The "quite broken" aspect is probably to do with the OO updates.  Can
>>>>>> i help atall??
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> _____________________________________________
>>>>>>
>>>>>> Mob:  07725 695178
>>>>>> Email: ma...@rw...
>>>>>>
>>>>>>
>>>>>> On 11/04/2011 21:05, Scott Miller wrote:
>>>>>>
>>>>>> Hey Isabelle, I am also attempting to work on the clockOnOff stuff, as
>>>>>> it appears to be quite broken...
>>>>>>
>>>>>> Yes the "change the date" stuff is in Javascript, but that doesn't
>>>>>> mean we can't embed PHP within the java stuff, but I would also like to
>>>>>> enhance, or even replace that whole area of the new system, so,
>>>>>> internationalizing that would probably be premature at this point.
>>>>>>
>>>>>> The submit times and supervisors stuff are the "not ready for prime
>>>>>> time" attempts at a submission & approval system for the timesheet system.
>>>>>> Again, internationalization of this area is probably premature...
>>>>>>
>>>>>> I would love to see the excel system name changes you've made, go
>>>>>> ahead and submit that.
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>> On Mon, Apr 11, 2011 at 7:43 PM, Isabelle Vergely <
>>>>>> ver...@fr...> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> My today commit on Directory branches/txsheet-2.0-demo/(=> Revision
>>>>>>> 293)
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> - Modifications for internationalization:
>>>>>>>  * en-GB.ini, fr-FR.ini
>>>>>>>  * clockOnOff.inc, clockOnOff_core_new.inc, clock_popup.php,
>>>>>>> stopwatch.php
>>>>>>>  * template.php, common.class.php, footer.inc
>>>>>>>  * absences.php, monthly.php, simple.php, weekly.php
>>>>>>> - Small modification in timesheet.css
>>>>>>>
>>>>>>> Questions on txsheet-2.0-demo:
>>>>>>> ------------------------------
>>>>>>> - I have also made changes for excel filenames more representative
>>>>>>> than
>>>>>>> "Timesheet_" . date("Y-m").".xls"; I can also commit these changes.
>>>>>>> - I would like to "translate calendar" when displayed for "Change the
>>>>>>> date"
>>>>>>> but it seems to be in js file; it is right?
>>>>>>> - What are the goals of the pages "submit times" and "supervisors"?
>>>>>>>
>>>>>>> Isabelle.
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Forrester Wave Report - Recovery time is now measured in hours and
>>>>>>> minutes
>>>>>>> not days. Key insights are discussed in the 2010 Forrester Wave
>>>>>>> Report as
>>>>>>> part of an in-depth evaluation of disaster recovery service
>>>>>>> providers.
>>>>>>> Forrester found the best-in-class provider in terms of services and
>>>>>>> vision.
>>>>>>> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
>>>>>>> _______________________________________________
>>>>>>> Tsheetx-developers mailing list
>>>>>>> Tsh...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Forrester Wave Report - Recovery time is now measured in hours and minutes
>>>>>> not days. Key insights are discussed in the 2010 Forrester Wave Report as
>>>>>> part of an in-depth evaluation of disaster recovery service providers.
>>>>>> Forrester found the best-in-class provider in terms of services and vision.
>>>>>> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Tsheetx-developers mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>