Re: [Tsheetx-developers] [SPAM] Re: Simple time sheet

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

Well, to me, there's nothing inherently wrong or bad with having these two
styles available, and I believe that part of the appeal for this system is
that it can do either style.  But, the way things are currently handled
makes switching between the two styles do things that can surprise the user,
and surprising users is generally a bad thing.

So, Peter, I believe the correct course of action is to attempt to fix the
surprises, not redesign the whole thing; which is what I'm concerned you
maybe thinking.  But, a form that allows for daily entries a week at a time
would probably be welcomed by those that want to track start/stop times.  If
it works well enough, I can see this replacing both the weekly and the daily
views; they would no longer be needed.  But building this new form will not
make any dent whatsoever in the issues we're discussing; and no matter how
well it works, I don't see it replacing the simple form.  But, I could be
persuaded with the right UI design...

As for the configuration table, for a submission/approval system to work, I
see the need to have a table with lots of per user entries that say what
weeks or months have been submitted and which have been approved.  There
have also been many requests to be able to "pre-populate" a new week with a
"default" list of tasks the user picks and a user selectable timezone are
just a few configuration options that could be useful in the future.  But, I
think the approval stuff probably should not be intermixed with user
configuration items; I just didn't think through that when making my "off
the cuff" remark.

-Scott

On Wed, Sep 22, 2010 at 11:56 PM, Peter Lazarus <pal...@gm...> wrote:

>  I agree, Scott that there are problems swapping between the two styles.
> And I can see in the simple form the work that has been done to aggregate
> multiple daily entries into one entry for display and editing.
>
> But precisely because there are issues in running the two styles on the one
> system, I think we need a different approach to make both consistent. Or a
> significant warning of the limitations of the simple time entry.
>
> Yes, in the simple form, the transaction ID field (trans_num in times db)
> can be used to track which time entry is which. I would rather throw the
> problem at the user though. If sometimes the user enters times on the weekly
> sheet and records start and stop time, then, when adjusting hours worked on
> the simple sheet, the user should be presented with the individual entries
> in some format, and he can decide which one to edit. On the other hand, some
> users will complain about that difficulty, and added complexity - it's no
> longer a simple form.
>
> So where my thinking is going at the moment is to leave simple.php as it
> is. I am toying with the idea of the weekly sheet with some simplified entry
> option. It currently displays for each task, the multiple time periods that
> have been worked. Perhaps we could allow these entries to be selected and
> edited. Perhaps a user could elect to enter either hours worked, or start
> and stop times. I need to think this one through a lot more though and draw
> up a mockup on paper.
>
> Submission and approval. Agree that this function needs to be in separate
> forms. Supervisor review, approve function needs to be in a separate form.
> But should the user submission be in a separate form, or another button on
> an existing form? Users may prefer to submit times from the weekly/simple
> sheets just after they have finished editing. But it would be simpler from a
> development point of view to do submission from a separate sheet.
>
> Re the user configuration table. What things are you thinking of putting in
> there?
>
> Peter
>
>
> On 09/23/2010 12:19 AM, Scott Miller wrote:
>
> Well, to be honest, the reason I'm currently advocating never to switch
> between them is because of the various problems that can crop up when doing
> this.  Start/stop times, if they exist, are wiped out to all begin at
> midnight, and week spanning entries can cause time losses or time
> replications.  There may be others, but these issues are currently
> non-trivial to fix, but they are easily avoided if you don't switch between
> the two input methods.
>
> I've thought about how to tackle these issues:  if we keep track of the
> transaction ID's within the simple timesheet, that appears to be a workable
> solution, but then when we throw the aggregation possibilities into the mix,
> things break down. But, iIf we kept a list of the transactions for the
> aggregations, maybe that would work?  If an aggregate is edited, throw out
> the individual entries and create a new one that starts at midnight.  If
> it's not edited, leave them alone.  For entries with a single transaction,
> the length could be edited, leaving the start time in tact.  This also helps
> make the week spanning time entries problems more easily solvable.
>
> As far as submission to management and approval go, I would highly
> recommend putting that stuff in separate forms.
>
> BTW, many things seem to hinge on having some sort of per user
> configuration tables.  Timesheet submission and approval seem to need these
> from what I've been able to figure out.  I would love to have a per user
> timezone entry, but then we need to fix the timezone problems...
>
> -Scott
>
> On Wed, Sep 22, 2010 at 6:05 AM, David Thompson <
> tom...@us...> wrote:
>
>> I would disagree with the view that you shouldn't switch between the two,
>> why not? Sometimes you just want to say I worked today from 7 to 18, and let
>> the TS work out how many hours that was, and other times you say OK,
>> yesterday I did about 4 hours.
>>
>> If the simple timesheet didn't have all the problems that Peter has
>> rightly identified, then it wouldn't be so tricky to swap between the two
>> styles of entry. I could imagine merging the simple and weekly timesheets
>> and offering the user the choice of style.
>>
>> Cheers
>>
>> > From: it...@ea...
>> > To: pal...@gm...; tsh...@li...
>> > Date: Tue, 21 Sep 2010 19:37:05 -0400
>> > Subject: Re: [Tsheetx-developers] Simple time sheet
>>
>> >
>> > I've got to agree with Scott... If you want to enter start and stop
>> times,
>> > use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple
>> > timesheet works great for those who only need to enter hours and minutes
>> and
>> > the start/stop times don't mean anything to us: just the time in the end
>> >
>> > -----Original Message-----
>> > From: Peter Lazarus [mailto:pal...@gm...]
>> > Sent: Tuesday, September 21, 2010 7:05 PM
>> > To: tsh...@li...
>> > Subject: [Tsheetx-developers] Simple time sheet
>> >
>> > I posted this comment on simple timesheet entry on the bug tracking
>> > system. Scott Miller has responded and suggested we discuss this issue
>> > on the developers forum. Can the wider community add their opinions and
>> > suggestions. Scott's response is reproduced further down.
>> > Peter
>> >
>> > I've been using the simple timesheet to add a function for submitting
>> and
>> > approving timesheets. The more I work on my new function I discover that
>> > simple timesheet has some inconsistencies with the other entry methods.
>> One
>> > issue that I don't like is that simple deletes the time records and them
>> > puts them back. This means quite a lot of detail can be lost.
>> >
>> > So can we suggest/design a new time entry format, perhaps similar to
>> > simple's approach. Some of the requirements I would like to see are:
>> > - enter times for the week against the projects/tasks
>> > - time entry must include start and stop times to be consistent with the
>> > other input
>> > - multiple periods on the one day against one project/task/description
>> > similar to what can be entered with daily or weekly
>> > - changes to existing times cause db updates rather than
>> > deletion/insertion
>> > - ability to submit time records for a week for approval (requires a
>> > supervisor) although submission could be done in another panel
>> >
>> > (0000231) Scott Miller (developer) - 2010-09-21 20:05
>> > http://bugs.timesheetng.org/view.php?id=109#c231
>> > ----------------------------------------------------------------------
>> > I agree that deleting records only to recreate them seems to be the
>> wrong
>> > thing to do, but keeping track of what items need to change then becomes
>> > necessary and that's not a trivial task.
>> >
>> > I totally disagree with requiring a start and stop time. Simple was
>> > designed for those who don't want to have to deal with start/stop times,
>> > and just want to be able to record time spent per item.
>> >
>> > That said, I believe that if start/stop times exist, they should not be
>> > deleted; again this is not trivial.
>> >
>> > For further discussion, please join the developers mailing list, and
>> lets
>> > discuss this there. You can find a link in the wiki area to join.
>> >
>> > One example of why these are not trivial problems is that simple.php
>> > currently combines multiple time entries for identical task/log
>> messages.
>> > How do you handle an edit of an aggregate amount of time?
>> >
>> > I personally believe that users should be free to choose which system
>> they
>> > want to use, but I highly recommend NEVER switching between time entry
>> > systems because they represent entirely different ways of
>> thinking/looking
>> > at time tracking.
>>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
> _______________________________________________
> Tsheetx-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>