Menu
▾
▴
Re: [Tsheetx-developers] txsheet-2.0-demo: new commit for internationalization
|
From: Mark W. <ma...@rw...> - 2011-04-13 15:43:09
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Scott, <br>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
The simple timesheet could be improved quite a bit by simply putting
the description field below the drop down menu fields.<br>
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.<br>
<br>
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.<br>
<br>
Can we keep the daily clocking roughly how it is but maybe add a
completely separate page for multiple clocks?<br>
<br>
Regards<br>
Mark<br>
<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 13/04/2011 14:45, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">Ah, I was not thinking about "mobile devices", so I
saw no point in stretching things vertically.<br>
<br>
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?<br>
<br>
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.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 10:26 PM, Mark
Wrightson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> 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.<br>
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.<br>
<br>
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.<br>
<br>
Maybe the message box restriction was in an old version of
tsheetx v1.2/v1.3<br>
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?<br>
<br>
<br>
<br>
Regards
<div class="im"><br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" value="+17725695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div class="h5"> On 12/04/2011 18:42, Scott Miller wrote:
<blockquote type="cite">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).<br>
<br>
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?<br>
<br>
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?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 5:18
PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt
0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> 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.<br>
<br>
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.<br>
<br>
A hybrid could work however? - Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client:<br>
</td>
<td valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="3" valign="top">Message:<br>
</td>
<td colspan="2" rowspan="3" valign="top">[Message
Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td valign="top">[12-4-2011 ] [8.00
AM]<br>
</td>
<td valign="top">Clock off:<br>
</td>
<td rowspan="1" colspan="2" valign="top">[12-4-2011
] [5.00 PM]</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top">[Clock on and/or off]<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
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?<br>
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.<br>
<br>
If you wanted to add lots of times could you do
it as follows:<br>
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:<br>
<br>
Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client1<br>
</td>
<td valign="top">Project1<br>
</td>
<td valign="top">Task 1<br>
</td>
<td valign="top">Description<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top">Client 2<br>
</td>
<td valign="top">Project2<br>
</td>
<td valign="top">Task 2<br>
</td>
<td valign="top">Description 2<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td colspan="2" rowspan="1" valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Client:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
<td colspan="1" rowspan="4" valign="top">Message:<br>
<br>
</td>
<td colspan="2" rowspan="4" valign="top">[Message
Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [8.00 AM]<br>
</td>
</tr>
<tr>
<td valign="top">Clock off: </td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [5.00 PM] </td>
<td valign="top"><br>
</td>
<td valign="top">Add another clock <br>
</td>
<td valign="top">Submit All!<br>
</td>
</tr>
</tbody>
</table>
<div> <br>
<br>
Cheers<br>
<br>
Mark<br>
<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" value="+17725695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 12/04/2011 17:11, Scott Miller wrote:
<blockquote type="cite">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.<br>
<br>
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.<br>
<br>
How does this sound? can we improve this
form even more?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12,
2011 at 2:48 PM, Scott Miller <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">Hey Mark,<br>
<br>
I'm going to add my answers to the
middle of your text below:<br>
<br>
<div class="gmail_quote">
<div>On Mon, Apr 11, 2011 at 10:50
PM, Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid
rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000"> 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??<br>
</div>
</blockquote>
</div>
<div><font color="#339999"><br>
</font>
<div style="margin-left: 40px;
color: rgb(0, 0, 153);">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
:-)<br>
</div>
</div>
<div>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid
rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000"> <br>
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:<br>
<br>
1. backup of db<br>
2.checks for any prerequisites<br>
3. performs db updates<br>
4. complete<br>
<br>
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.<br>
<br>
an upgrade basically consists
of a new class file called for
example:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
so another file could be
created i.e.<br>
upgradev1_5_3_to_v1_6_0.class.php
in which case only a single
upgrade step<br>
is required and that will work
fine (but starts to get labour
intensive creating files for
every permutation).<br>
<br>
I've written a script that can
work out the necessary upgrade
path i.e. <br>
going from v1.5.3 to v1.6.0<br>
run the following upgrades:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
upgradev1_5_4_to_v1_6_0.class.php<br>
<br>
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. <br>
<br>
Have you got any thoughts on
this problem? <br>
</div>
</blockquote>
</div>
<div><br>
<div style="margin-left: 40px;
color: rgb(51, 102, 102);"><span
style="color: rgb(0, 0, 153);"> 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.</span><br style="color:
rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">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.</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">The upgrade should not
attempt to figure out what
code files need to be
changed/added/deleted. The
upgrade process should look
like this:</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">1. Old installation
with old database</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">2. download new version</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">3. unpack the new
version</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">4. rename the old
version's directory something
different: tsx -> tsx.old
or use version numbers or
whatever</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">5. move the new
unpacked version to the
original directory's name</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">6. optionally copy a
configuration file or two from
the old system to the new
system to assist with the
upgrade</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">6. open a web browser
to the site</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">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.</span><br>
</div>
<br>
</div>
<div>
<div>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid
rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000"> Cheers
<div><br>
Mark<br>
<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" value="+17725695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 11/04/2011 23:33,
Scott Miller wrote:
<blockquote type="cite">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. <br>
<br>
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.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Mon, Apr 11, 2011 at
10:30 PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin: 0pt
0pt 0pt 0.8ex;
border-left: 1px
solid rgb(204,
204, 204);
padding-left:
1ex;">
<div
bgcolor="#ffffff"
text="#000000">
Hi Scott, <br>
<br>
The "quite
broken" aspect
is probably to
do with the OO
updates. Can i
help atall??<br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" value="+17725695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<div>
<div> <br>
On 11/04/2011
21:05, Scott
Miller wrote:
<blockquote
type="cite">Hey
Isabelle, I am
also
attempting to
work on the
clockOnOff
stuff, as it
appears to be
quite
broken...<br>
<br>
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.<br>
<br>
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...<br>
<br>
I would love
to see the
excel system
name changes
you've made,
go ahead and
submit that.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Mon, Apr 11,
2011 at 7:43
PM, Isabelle
Vergely <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ver...@fr..."
target="_blank">ver...@fr...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;">Hello,<br>
<br>
My today
commit on
Directory
branches/txsheet-2.0-demo/(=>
Revision 293)<br>
------------------------------------------------------------------------<br>
-
Modifications
for
internationalization:<br>
* en-GB.ini,
fr-FR.ini<br>
*
clockOnOff.inc,
clockOnOff_core_new.inc,
clock_popup.php,
stopwatch.php<br>
*
template.php,
common.class.php,
footer.inc<br>
*
absences.php,
monthly.php,
simple.php,
weekly.php<br>
- Small
modification
in
timesheet.css<br>
<br>
Questions on
txsheet-2.0-demo:<br>
------------------------------<br>
- I have also
made changes
for excel
filenames more
representative
than<br>
"Timesheet_" .
date("Y-m").".xls";
I can also
commit these
changes.<br>
- I would like
to "translate
calendar" when
displayed for
"Change the
date"<br>
but it seems
to be in js
file; it is
right?<br>
- What are the
goals of the
pages "submit
times" and
"supervisors"?<br>
<br>
Isabelle.<br>
<br>
------------------------------------------------------------------------------<br>
Forrester Wave
Report -
Recovery time
is now
measured in
hours and
minutes<br>
not days. Key
insights are
discussed in
the 2010
Forrester Wave
Report as<br>
part of an
in-depth
evaluation of
disaster
recovery
service
providers.<br>
Forrester
found the
best-in-class
provider in
terms of
services and
vision.<br>
Read this
report now! <a
moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo"
target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</a><br>
_______________________________________________<br>
Tsheetx-developers
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Tsh...@li..." target="_blank">Tsh...@li...</a><br>
<a
moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers"
target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a><br>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
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! <a moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo" target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</a></pre>
<pre><fieldset></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" href="mailto:Tsh...@li..." target="_blank">Tsh...@li...</a>
<a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
