On 12/12/13, 8:01 AM, "Cliff Perry" <[email protected]> wrote:
>On 09/12/13 07:45, Duncan Mac-Vicar P. wrote: >> On 09/12/13 05:32, Jan Pazdziora wrote: >> >> (and code attached) >> >>> Nice idea. >>> >>> There is a problem with the general inconsistency of the date/time >>> displays, and part of it stems from the fact that Java does it >>> differently than Perl. >>> >>> What is the proposal for the Perl side of the code base? If there is >>> going to be some mass deployment of the new tags, it would be good to >>> make it a full audit of the time formatting usage and do it >>> everywhere. >> >> mmmm... Johannes was pushing for the moment.js option (client side) and >> I convinced him on the server-side solution, but I did not think about >> perl. Doing it client side would solve the problem. >> >> I will try a different implementation using moment.js. > >Of course, how much perl code is to remain, soon? > - So, that maybe is something that can be mitigated with plan to >continue converting perl pages to java. > >Client side rendering via js is reasonable - dumb question - where/what >does the locales? :) > - I do like the screen shots and idea of making date/time stuff easier >to read - I've also seen people wanting date formatting displayed >changed. Just because their language is English, doesn't mean that >11/12/13 is clear to them - since in America is is 12th November and in >UK it is 11th December. > > >> >>> And of course -- there may be people who prefer the exact dates/times >>> to be shown so this really should be configurable. For new >>> deployment/users, I assume the new behaviour would be fine but for >>> existing users, we might want to preserve the existing behaviour, >>> and let the users change it manually. >>> >> >> I disagree in making configurable (software complexity increases a lot >> adding little value), but if in order to get the patch upstream it is >> needed, with the client-side solution this should not be hard to >>achieve. >I agree that I disagree with Jan here. I know some may grumble, but >where it matters, within spacewalk-reports, APIs, etc - the data is >given in usable/precise manner. > >If done client js, they can use browser plugin's to disable execution of >specific js's, so it would render the old way. > >Cliff >> >> Duncan >> >> _______________________________________________ >> Spacewalk-devel mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/spacewalk-devel >> > >_______________________________________________ >Spacewalk-devel mailing list >[email protected] >https://www.redhat.com/mailman/listinfo/spacewalk-devel > Late to the party, I know .. 1) I know a lot of “users” (non-technical) who really don’t like the trends out there towards ”Yesterday” type relative dates (personally, I hate it). If they see YYYY/MM/DD (or whatever, like March 3, 2014), it’s really easy to note the differences on other rows. 2) Approximations as the only option are especially hated by end users. When it says, “about a month ago” (for anything from 2-7 weeks old, or whatever), then it’s just about as completely useless. Let’s also remember that our user base are people who need to deal with some absolutes. In an environment with hundreds or thousands of systems, managing them with a tool like Spacewalk is a godsend, but we also have to compare, track, report stuff from time to time. If I need to know which systems all received OS updates on the same day last November, I need to easily and handily get that info when sorting a list. 3) I also know a lot of people who hate *not* having choice in how something like dates are displayed. 4) You can’t please all of the people all of time, right? Well, no matter what default is set, this axiom will come into play. That’s OK, but by giving some flexibility to the users, we win a TON of points with them. Therefore, I suggest: 1) Whatever is decided on as the “default” is fine, as long as it’s configurable. 2) Configuration should provide 2x2 tweak able options: ================ Short Dates: Format: [ YYYY/MM/DD ] [ ] Include Relative Dates (e.g., ‘Yesterday’) Long Dates: Format: [ Day, Month Date, Year ] [ ] Include Relative Dates (e.g., ‘Yesterday’) ================ (making the values whatever defaults based on locale and such) In this way, we can use whatever format makes sense for a given page (long v. short) and the user can see what they expect and are most comfortable with. -- Lamont Peterson Sr. Systems Administrator | Unix Systems Operations Intermountain Healthcare Office: 801.442.6497 _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
