I missed most of the fun the first time the new transaction history was launched. It was launched unannounced. It appeared to annoy pretty much everyone who saw it. It appeared to be pulled again pretty quickly. I get the impression that it wasn't so much launched as it escaped.
But, now, we have it and we've being living with it for a week or so. And it's terrible. Really terrible.
Let me be clear: I generally do my best to not be one of those people who abhors change. If something changes I'll try my best to understand where the motivation for that change came from and, as much as possible, I'll try and adapt.
No, the reason why I say the new transaction history is terrible isn't because I dislike change. What I dislike is change that removes utility and makes life harder for little or no obvious benefit. From where I'm sat right now the new transaction history appears to do that, it appears to have been developed by people who don't actually use the transaction history or realise how it's used.
First off, there's the problem that I've seen most people mention: you can't easily select a single day to view. As I write this it's 2014-06-11 here (I'm in the UK). It's also 2014-06-11 in SL too. I want to view all of my transaction history for today so far so the obvious selection would be to set the start and end date to 2014-06-11. That's how the old transaction history worked. It worked. Not now though, if I do that now I get:
Please specify a correct date format of YYYY/mm/dd and ensure the start date occurs prior to the end date.
Okay, fine. So to view the history for today I have to set today as my start date and tomorrow (which is in the future as of the time of writing) as my end date. Apparently I have to work for the system, not the other way round. Apparently the system is coded such that it can't do a sensible comparison when validating my input (and, presumably, no longer does a sensible comparison when selecting the data).
Anyway, I set my start date to today and my end date to tomorrow and, sure enough, I get today's transactions (sort of, more on that a little later).
But what if I want to view the transactions for a single day from a few days ago? Based on what I'm seeing above the idea is that I should make the day I'm interested in the start date and the following day the end date. If I'm to follow the above then it would seem that the range is inclusive of the start date but exclusive of the end date. So, I do that, and I get....
...two days worth of data! Data from the start date and data from the end date. So it seems that it's inclusive of the start date and end date but the end date always has to be greater than the start date so the only way you can get data for a single day is if the following day has no data -- or the following day hasn't happened yet.
Yeah, you could say I'm astonished.
And the thing to remember is this: before the changes this worked just fine. I could select a single day and I'd get data for that single day. I was not in the least bit astonished by that.
But it gets even better. Starting today (I think it started today) the transaction history is now showing me transaction times in my local timezone. On the surface that might actually seem useful. But, really, it isn't. Not for me it isn't. Here's why:
Second Life is a global environment. People from all over the world, at all longitudes and latitudes, interact with each other, work together, build together, play together, run and attend events together. The thing that makes all of this work is a common understanding of time. Second Life, as we all know, uses a timezone that is the same as the Lab's office. Personally I think that's a bad choice; personally, if it had been me, I'd have gone with UTC. But that doesn't matter. What matters is that, no matter where you are in the RL world, the SL world has a common time.
This makes organising everything so much easier (well, apart from when they break the code or, as happened earlier this year, forget to take DST into account).
Miss Vila is also my business partner. One of us is in the UK, the other in Australia. We have customers from all over the world, in all sorts of timezones. I keep and update our sales records based off what she sends to me; we both support our customers based off what they tell us. It serves no useful purpose whatsoever for her to see those sales in her local timezone. It especially serves no useful purpose when she emails those sales to me and they're in her local timezone which isn't my local timezone which isn't SL's timezone.
Even better: the transaction history, as it appears right now, doesn't even match what you see in a) the marketplace sale notification emails or b) the marketplace order history report. From the point of view of a Second Life merchant the SL merchant tools are not internally consistent. (from what I can see it is actually internally consistent1, it's just presented in a way that makes it look otherwise).
It's a mess.
And then there's the fact that it doesn't remember my preference for how many items I'd like to view....
And then there's the fact that one date format is used to display times (a form of ISO 8601, an excellent choice) and yet in the date input/picker they use a slightly different format.
Really, it's a mess.
The thing is, I get what they're trying to do. The ability to better control what you see, especially the filter, makes so much sense. I really like that as an idea. But how the heck did what we see now make it past any kind of quality control? There's no need whatsoever to break how things used to work just to add this feature.
There just isn't.
What I find so utterly frustrating about this is that timezones and time are a really difficult problem. Really, for a programmer, they are:
And the nice thing is that the Lab had it sorted. They gave the grid a single timezone and used it everywhere. And now they've broken that.
I hope this isn't on purpose.
1 If you're comfortable using your browser's console you can see that, internally, the model object that holds the current data has the time of the transaction as a JavaScript time object and that the time is correct. Try:
angular.element("#history-table").scope().history.historyDataMod[0]
and inspect the result to see (assuming you've got at least one row of history showing).
No comments:
Post a Comment