Page MenuHomePhorge

Refactor ShoutWiki Calendar extension (tasklist)
Closed, InvalidPublic

Description

(It can be tested at http://social-tools.wmflabs.org/wiki/Calendar)
Someone I know always says "don't reinvent the wheel!" (cough @jack cough ) so I decided instead of doing that, is to help and improve this. :P
There are 6 main flaws that I've found in the Calendar extension, which are listed down below as subtasks:

  • Readability: See T100
  • User control and feedback: See T101
  • Navigation: See T102
  • Design: See T103
  • HTML & CSS: See T104
  • Datepicker: See T105

Event Timeline

SamanthaNguyen triaged this task as Normal priority.
SamanthaNguyen updated the task description. (Show Details)

Can this be broken / merged into more manageable chunks/problems and file those as separate tasks. Refactoring an entire extension as one task makes it less manageable.

Can this be broken / merged into more manageable chunks/problems and file those as separate tasks. Refactoring an entire extension as one task makes it less manageable.

Echoing this, mainly because my screen is what's considered small these days (resolution-wise) and having to scroll up and down all the time is annoying. :P

@SamanthaNguyen Some more detailed thoughts about the issues you mentioned...

  1. Readability -- agree with everything. This design is (AFAIK) the original design, which is some 9+ years old, which explains a lot of things. re:i18n, do you mean <abbr title="Monday">M</abbr> or so? In that case, new i18n messages won't be needed as core provides messages for all weekdays, abbreviated (three-letter in English) weekdays, months, abbreviated (three-letter in English, i.e. apr for April) months, month names in the genitive case and nowadays even dates in certain months (the messages <monthname>-date, i.e. january-date, for which the default is January $1).
  2. User control and feedback -- add cursor: pointer where? The cursor changes to the hand one when hovering the mouse over the previous/next links at least for me on my IE11.
  3. Navigation
    1. The AJAX bug is that when you click on the previous or next month (let's assume next), you'll be shown that month's stuff; for August 2016, there's the "Events Upcoming" section (although it's empty right now, obviously, because there are no events for August in that testing wiki). When you click on the "next month" arrow again to bring up September 2016, the "Events Upcoming" section isn't there. Click next month again to bring up October 2016, and there it is.
    2. As for lag, I frankly don't see it on that Labs wiki. There can be some minimal lag because each click on the previous/next month arrows actually makes an AJAX request to the API module, so it isn't exactly as fast as, say, showing some element that exists in the page source but is hidden via CSS.
    3. Good point about the date picker. Could we leverage jQuery UI's datepicker here? (SocialProfile uses this on Special:UpdateProfile for the birthday field, IIRC)
  4. Design
    1. WikiFont seems like a designer's Swiss knife, and to a certain extent it is that. However, from a developer's point of view, it's not quite that simple. Loading the whole WikiFont on all pages (that use the Calendar extension) seems unnecessarily heavy, not to mention that it probably won't work under IE11 without lots of dark magic (just like how it doesn't work with the Refreshed skin under IE11). The other option is pulling the desired icons (.svg files) from the WikiFont repo and bundling them with the extension, as I've done with the not yet merged SocialProfile Echo support patch. This approach isn't problem-free either, as the icon files can get outdated, but it's somewhat more functional and lightweight than including the entire WikiFont font (IMHO at least).
  5. HTML & CSS -- adding classes should be trivial and will definitely help with customizability.
SamanthaNguyen removed SamanthaNguyen as the assignee of this task.

Closing, as simply not interested anymore and most likely not going to invest this in any time soon.

Also... In any case, I'd say it'd be better to not have the extension reinvent the wheel and do our own style, and probably have it rewritten to use one/both of Core's date/time/calendar widgets like (not meant to be in this ticket; probably in a separate ticket, but currently I don't think it's worth to create a ticket for it as it's not really much of a priority):

  • CalendarWidget ( implementations: JavaScript )
  • DateInputWidget ( implementations: PHP and JavaScript )
  • DateTimeInputWidget ( implementations: PHP )