I plan on designing a new widget for office hours. Although there's a lot of work already put into the current widget, I feel the user friendliness of it severely lacking as it requires far too many clicks to set even the most basic set of hours.

My goal is to maintain database compatibility with the current implementation, and to that end I could implement this as a submodule, or replace the existing default widget. My preference would be to replace the default widget as the current implementation relies on a number of work-arounds and I don't feel it uses the FAPI in the way it was meant to be used.

I'll be starting work this weekend and welcome any requests, ideas, comments or concerns.

Regards,
Laz

CommentFileSizeAuthor
#19 google.png27.5 KBgiorgio79
#19 compact-idea-office-hours-drupal.png15.84 KBgiorgio79

Comments

johnv’s picture

johnv
Primary language Dutch
commented

Perhaps this will help you?
http://drupal.org/project/opening_hours
I haven't tested it yet myself.

Lazarus-Long’s picture

Lazarus-Long commented

A few more details:

  • The widget will not implement any new functionality such as exceptions. It will allow those to be added in the future
  • The selects for the start and end times will NOT be split into hours and minutes, but be one long drop-down. Having two selects just doubles the number of clicks required
  • I believe the current database schema will allow unlimited numbers of days/hour-blocks as the day is included as a column. The day seems to be multiplied by 2, but it's consistent logic that can be worked with. So, it should be possible to add as many open blocks (hours) on the same day as the user would like
  • The default form will include all 7 days, and allow a set of grouped days via checkboxes on each line. Clicking a checkbox will disable all the select fields except the first day, and the values from the first day in the group will be copied to the other fields. This will be implemented in Javascript. Keeping the grouping persistent through multiple edits may not be possible without schema changes
  • Additional days will be added below the default 7 days. Each additional day added will allow the user to select the day and times for the additional block/hours
Lazarus-Long’s picture

Lazarus-Long commented

Hi johnv,

I did see that, but I haven't tested it yet myself either. I have a few ideas of my own I'd like to do down the line, but the first is rebuilding the widget as I think it may be difficult to work around in the future (no offense).

A few examples from my personal roadmap: exceptions, a default block (both suggested by jeffam in the simple hours merge), token support (hours, hours for day of the week, hours for today, current status, etc), and possibly some kind of integration with the Calendar project (exceptions pulled from holidays on the calendar, display hours for each day on the calendar, etc).

johnv’s picture

johnv
Primary language Dutch
commented

Hi Lazarus-Long,
Sounds like an ambitious roadmap! Looking forward to it!

Perhaps you can brows through the open issues, set them to D7, and assign them to your name.
Then we get a proper list..

The selects for the start and end times will NOT be split into hours and minutes, but be one long drop-down. Having two selects just doubles the number of clicks required

Ozeuss just added such a list to the field settings. IMO this is not the most user friendly option. Indeed, it saves a mouse click, but needs scrolling through an enormous list, aspecially if you allo quarters or minutes.

I believe the current database schema will allow unlimited numbers of days/hour-blocks as the day is included as a column.

You might be right, the column _day contains odd number for 'more hours'. This might be skipped in favour of column 'delta'

My goal is to maintain database compatibility with the current implementation

A database change should not be a huge problem. keeping the current database schema, you might consider using the notation from Date-field:
- oh_field_starthours = 1000 vs. date_field_value = 2001-01-01T10:00:00
- oh_field_endhours = 2200 vs. date_field_value2 = 9999-31-12T22:00:00
Then, extra days can be added with e.g. column 'day' = 99, like the next example for Valentine's day.
- oh_field_starthours = 2012-02-14T10:00:00
- oh_field_endhours = 2012-02-14T22:00:00
Adapting the date-notation might make our code much shorter, too.

Ozeuss’s picture

Ozeuss commented

Laz:

The selects for the start and end times will NOT be split into hours and minutes, but be one long drop-down. Having two selects just doubles the number of clicks required

What johnv said. On the 5.x version we actually used such a select list, and moved to this one also to be more 'aligned' with dateapi and use less homebaked helper functions (as you can see many as is). Most people use granularity less than 'hours', so there's not much to be gained from changing back.
Johnv:

This might be skipped in favour of column 'delta'
A database change should not be a huge problem

Believe me, a database change is not something you want to venture in if you want to retain sanity. There's just not much functionality to be gained from that. Needless to say, there will be no database change without a tested migrate path.

johnv’s picture

johnv
Primary language Dutch
commented

OK, a database change is not a preferred option ;-)

This might be skipped in favour of column 'delta'

With this I do not mean to remove the column, but (in case you would need +2 hours-blocks per day)
Current situation, where day has a meaning (odd = more hours, even = first hours):
delta/day = 0/0 = 1000-1700
delta/day = 1/1 = n/a
delta/day = 2/2 = 1000-1200
delta/day = 3/3 = 1300-1700
delta/day = 4/x = 1800-2100 = not possible

Alternative situation, where day = just day, and delta counts the hours blocks:
delta/day = 0/0 = 1000-1700
delta/day = 1/0 = n/a
delta/day = 2/2 = 1000-1200 = 1st block of hours
delta/day = 3/2 = 1300-1700 = 2nd block of hours
delta/day = 4/2 = 1800-2100 = 3rd block of hours
As Lazarus-Long said, switching from type 1 to type 2 only needs an adapted algorithm.

Lazarus-Long’s picture

Lazarus-Long commented

Using the date field notation wouldn't be that useful as it would also store a date and not just a time of day. I can only see this complicating things.

Likewise, there's no reason to use delta to derive a day. The 'day' column already contains the day*2, and there's no limitation on them being unique. We could update the database to use just day (instead of day*2), but that could cause issues on existing sites. Regardless, there would be a change to the display formatter to accept more than 2 values for each day, but it's not a huge change (at least in the formatter refactor that I submitted earlier).

The only database change I would consider at this point is adding a "grouped" column to persist the grouped feature.

Lazarus-Long’s picture

Lazarus-Long commented

What johnv said. On the 5.x version we actually used such a select list, and moved to this one also to be more 'aligned' with dateapi and use less homebaked helper functions

Having multiple drop-downs also introduces problems with limiting the hours. 3:00 am may be invalid while 3:00 pm is valid, but multiple drop-downs will allow both. The only way to stop that is with JS or validation on the server side, which again is not very user friendly.

Another option is to get rid of the drop-downs altogether and use text field inputs. Again, more validation on the server side, but possible.

giorgio79’s picture

giorgio79 commented

One suggestion:

Instead of having a row for each day, the widget could have one row initially, sg like this

Day 1 - Day 2 Time

So one could specify repetition easily
Mon - Fri 10:00 - 24:00

Currently it is

Day Time
Mon 10:00-24:00

johnv’s picture

johnv
Primary language Dutch
commented

Starting with 1 line would be a good way to avoid repetitive entries.
We would then have 2 buttons:
- [Add more hours for this day] (in your plans you could have 3 bocks of hours per day, don't you?)
- [Add hours for the next day] or [Add hours for Tuesday]

When changing existing data, you would open all 7 days at once, I think, even the closed ones.

johnv’s picture

johnv
Primary language Dutch
commented

About the date notation:
Having a time period in the field would allow summer time and winter time.
If a venue is open only temporarily, you can set a from and to-date. Normally that would be from 0001-01-01-00:00:00 to 9999-12-31-23:59:59
It can be stored in the current integer field, as Date field does, too.
In fact, an OH field, is a 'repeat date'. The current 'Date-repeat date' doesn't seem too optimal to me, since is stores every instance of a date in the DB.
The exceptions could then be stored in the same DB-table as the regular opening hours.
Complying to Date field standards could make Views integration easier.

Lazarus-Long’s picture

Lazarus-Long commented

giorgio79, I really like the idea of "DayStart -> DayEnd: TimeStart -> TimeEnd" all on one line. It should still be compatible with the current schema too. I think I may make 2 different styles: one with a DayStart -> DayEnd, and one with a row of 7 labelled checkboxes (one per day).

johnv, the current schema will support an unlimited number of blocks per day, so that's how the widget will be made. I like the idea of adding more days, but the way the one-block-per-row layout will work, I think we can skip the [add more hours for this day] button. We'll try a few variations to see what we like.

I'll see what we can do about complying with the date field, but we have to remember that these aren't dates. They are times of day, which can be translated to date-times if we have a point to start at. For now, it may be easier to ignore dates until we have exceptions and calendar integration going.

johnv’s picture

johnv
Primary language Dutch
commented

Some hints for Views integration: http://erikwebb.net/blog/providing-date-module-functionality-custom-date-fields

Gastonia’s picture

Gastonia commented

Recently, I was redirected here from my feature request at http://drupal.org/node/1653656. However, I don't understand what this topic is about. It feels like there is another thread or something I should already be familiar with.

When you say 'widget' do you mean something that is a plugin to the office hours module? Or do you mean you are redesigning the office hours module from the ground up?

What are the goals, specs and requirements of the new 'widget' you are developing? What is trying to be achieved?

If I should be familiar with another thread before having read this one, please point me in the right direction. Thanks!

Gastonia’s picture

Gastonia commented

Despite my earlier post, here is what I would like to discuss:

Currently implementing hours for a large number of locations is extremely tedious and time consuming. If a location has two sets of hours and open every day of the week, you have around 60 clicks to make before being done with this part of the form. PHEW! Need a beer after that!!

What makes this part so frustrating is that 98% of the time M - F hours are going to be exactly the same. Sat and Sun hours have a little more variability, but mostly the same as well.

What I would like to propose is a simple javascript link that is listed to right of each day's block of time that reads "Click for previous days hours" - "Click" and then that field, with one click, is populated with those of the field above it (the hours of the day above it). If the hours are split, then the script splits and then populates accordingly. Provided that M - F is the same, and Sat and Sun are the same, you reduce the number of clicks from around 60 to around ... 10, maybe. That's 600x faster!!!!

Also, this change requires no change to the module or database at all. It's just an added layer of javascript.

Thanks!

Lazarus-Long’s picture

Lazarus-Long commented

Hi Gastonia,

"Widgets" are the parts that let you enter data. You can have multiple types of widgets for the same field type (such as radioboxes, check boxes, drop-down select, could all be used for the "options" field).

This thread is for a redesign of the data entry. It would not involve editing times for multiple entities, but would make entering information for any one entity easier. If you need to enter the same information for multiple entities, I would suggest looking at Views Bulk Operations (though I haven't tested this yet).

Gastonia’s picture

Gastonia commented

No, I think there a misunderstanding here. I am talking about one entry. On one single entry you have more than 60 clicks before you are finished entering hours for one single location.

My proposal is to create a link that prepopulates the current day with the hours from the previous day, thereby reducing significantly the time necessary to finishing populating hours for this one entry (location).

Please let me know what is unclear about my above post so I can better clarify. Thanks!

Lazarus-Long’s picture

Lazarus-Long commented

Hi Gastonia,

I understand what you mean, and that is part of the widget redesign changes discussed above (grouping days within the same entry). Keep an eye on this thread. I'll keep it update with new changes.

At the moment I'm working a fair amount, but I'll try to get something going this weekend.

Laz

giorgio79’s picture

giorgio79 commented
StatusFileSize
new compact-idea-office-hours-drupal.png15.84 KB
new google.png27.5 KB

#10 Thanks johnv
#12 Thanks Lazarus-Long! Appreciate it and look forward to assisting.

I even put up an image for the visual types :). I also researched how others do it, and including a screen of how Google Places does it at the moment.

dsrikanth’s picture

dsrikanth commented

Subscribing..

WebmistressM’s picture

WebmistressM commented

I would be interested in offering more than just 2 blocks of time a day where my business is open. We are a mostly 24 hour business as we operate online.

.......subscribing

Daniel Schaefer’s picture

Daniel Schaefer commented

I think it would be a great improvement already to just have an option to take the first set of hours and fill all blank fields with that. Would save me a lot of work, I'm working on a kind of business catalogue and most business have hours like: Mo-Sa 10-23, So 12-23 e.g.

Also, I think free input fields are better than select fields - at least would make it faster for me.

johnv’s picture

johnv
Primary language Dutch
commented

ITMT there have been some developments. The below features are in the latest -dev version and will be incorporated in version 1.2:
1- the widget settings page now has default values for the complete week.
2- an unlimited number of locks per day is supported. The js needs some UX work.

johnv’s picture

johnv
Primary language Dutch
commented

The office_hours widget contains 3 levels, since it defines 2 'elements':
1- the widget form
2- the 'office_hours_block' , with a separate widget for the fieldset 'daylabel+starthours+endhours'
3- the 'office_hours_select', with a separate widget for the individual times

Level 3 can be developed separately, using #1676648: Alternative jquery timepicker for Office hours (D7)
Patches are welcome.

aze2010’s picture

aze2010 commented
Issue summary: View changes

very hot feature/widget!
how its going on?

subscribing!

johnv’s picture

johnv
Primary language Dutch
commented

Regarding #21 , #23-2: #1945230: Javascript for 'N time blocks per day' is not complete is now fixed.

johnv’s picture

johnv
Primary language Dutch
commented
Status: Active » Closed (won't fix)

@Lazarus-Long, I suppose you've moved along. Also, the widget has been improved, since.

This issue hass too much sugggestions to be workable.
Shall we close this issue, and make progress with smaller suggestions from other issues? If you feel like taking this one up, please do!
But I think that working on a D8-version is a better idea!