Progress Towards 1.5.0

ok

My idea was this:

1. (root menu) > Extensions > Reports

This page would allow users to install, uninstall and, if applicable, configure report settings. For example, the user may be able to categorise their reports (such as Sales Reports or Customer Reports) and also choose which reports show by default on the 'Reports' page -- see item (2) below. By being able to categorise the reports, the 'Reports' menu (below) could be dynamically populated using the categories as submenus.

2. (root menu) > Reports

This page would be completely separate to (1). It would show the default reports selected for viewing by the user (set in the Extensions area), and provide links to view other reports. It would be like a landing page to view reports as opposed to a page where they are configured. The Extensions area would purely be to install and configure each report, not display them.

This way both pages are placed in a 'logical' place from both a developer and user perspective. They are not duplicates as their functionality is completely different.

I see now, but reports aren't really "configured".. at least not the current ones, other than the filtering at the top of the sales report, what other types of semi-permanent configuring would a report need? I'd think the filter method at the top and maybe the ability to "save as default" would be ideal for a report

Well if the reports were able to be categorised (so as to show in the navigation under that same grouping), that would be one thing. Also some reports may have options such as 'graphical' or 'text-based', or default date ranges etc.

I'm just trying to think about it for the future as well. Who knows what kinds of reports will exist and how they could be configured? In any case, the distinction between display and installation/uninstallation is surely enough to please everyone by having a separate 'Reports' menu.

Also, I can see your viewpoint about where the line is drawn (i.e. do we start making root-level menus for all of the other types of extensions), but that's one of those questions where the answer comes down to common sense. Not everything has to be a hard and fast rule so Reports would be ok to make a separate menu for, because it warrants it. Other extensions don't warrant their own menu at present.

Well the way it will be done is like i said above.. a javascript to fake it and add all reports to the menu reports dropdown will simulate clicking the "View" link. The actual reports page that lists them all will have the same options that all modules do. Reports will typically only have "view" but will support other "actions" for those that want to include a configure option, and that will all be internal to the report itself to be handled.

That will actually be another hook to allow different actions based on what actions the extension offers. Currently modules have "install/edit/uninstall" but they can support more with a hook.

I understand. I just thought perhaps the Reports 'landing page' could really be improved by having multiple reports (particularly graphical ones) show by default. The entire page could be customised by allowing users to drop and drop report 'widgets', in a similar way to the proposed layout editor, which would give quite a lot of flexibility. Again, just an idea for the future, but if you figured out a rough plan now then it might factor into your thinking when adding reports to the current menu.

OHHH i see what you mean now
like the dashboard has the charts and quick total sales breakdown... you want a reports page for graphical reports.
I understand now.. that is a good idea actually

Perhaps that would be a good feature.. for the dashboard to be configurable to show select reports for immediate viewing.

And again I see nothing...
Probably the joke was successful and we will see the release 1.5.0 by December this year!

ZING! you figured it out

On the topic of reports, it would also be good for users to be able to define what "year" means
for countries which have financial years that do not end on 31 Dec

I got a half second scare today when I looked at my dashboard and saw that Sales for the Year was blank. I thought I had broken something else again until I remembered year is calender year.

ahem:

Non-programmers will not understand why they have to go through the extension menu to get reports on their shop.

Unless these are settings we are talking about which would be a different issue.
And then, yes, then I'd have all the settings under 1 main category.
Or if this a mod/extension "install" type of issue, and then they should be under a "extensions / updates / downloads" type of area.

I am looking at this from the viewpoint of the end user wants to view reports.
So,I should have asked in the beginning, what type of functionality are we talking about?
settings, install, or usage?

I did mention separating So, I'm glad that OneilDesign was able to put this done in an easier to understand way

This is what I was thinking of last night:
exentionsions (root menu) settings (root menu) "reports" (root menu) <<< as per user usability
... install/edit ... extensions .... visual data and graphs
... (code stuff) ... (settings/preferences) .... ask X said -- MBA nonsense

Essentially, as I said settings, install and usage.
3 items in 3 areas, simple and neat. The user will be able to find things based on what it's purpose is
should have wrote this last night.

Since we are looking at menus:
Why is there a Sales (root menu) and then under Reports (root menu) >> Sales (sub-menu) ?

To be honest, if you view the layout that way you could organize things better and have a clearer understanding how things work.
This will also reduce most of those post of how do I set blah blah and can I do blah blah .
Because you can and you didn't know because you couldn't figure it out without it being pointed out.

@ahem.. i see no similarities in the context

jty wrote:On the topic of reports, it would also be good for users to be able to define what "year" means
for countries which have financial years that do not end on 31 Dec

I got a half second scare today when I looked at my dashboard and saw that Sales for the Year was blank. I thought I had broken something else again until I remembered year is calender year.

Ouch, accounting practices.
Yeah, I can see that when you are thinking fiscal year vs the Gregorian calendar year.

By country and by company ...
I doubt this is up for 1.5 but I can see this being part of a larger and wider change to the system to take into account of sales tax issues, resetting of numbers based on end of fiscal year, the setting of fiscal year reporting and such.

I have to deal with:
- country's fiscal year ending in March
- my company's fiscal year ending in December (friggin' US issues)
- sales tax being included in price
- restting of all data numbers (can get around but ... keeps internal account neat and easy to read)
- keeping a running ledger from previous year
--- not even going to mention income from several distinct different sources but this is not a cart issue

This is an area that opencar could differentiate itself from others. Having a system that isn't just US centric.

Qphoria wrote:@ahem.. i see no similarities in the context

too short to understand between what and what

@ phpbb
crap, I had spaced that out with spaces ...

jty wrote:On the topic of reports, it would also be good for users to be able to define what "year" means
for countries which have financial years that do not end on 31 Dec

I don't think that has anything to do with countries. A business year that ends on 12/31 is called a "calendar year" and one that ends on any other day is called a "fiscal year". We have it here in the States, as well. It all depends on how you set up your business.

I haven't looked (because we're calendar year based) but if OC doesn't have a way to enter the 'year ending date', then it should for businesses that need it.

Marc

marc_cole wrote:I haven't looked (because we're calendar year based) but if OC doesn't have a way to enter the 'year ending date', then it should for businesses that need it.

I certainly haven't found this in settings, but it should be a pretty small change in the code... I'll have a look at it if I remember after I wake.

OK, as this thread has got rather long now and filled with technical jargon can we just have a recap of some of the salient points.

1. The current templates won't work with 1.5?

2. As well as the desperately needed integrated shipping estimator, will PayPal Express and Google Checkout definitely form part of the core of this new program?

3. Will the new version be compatible with IE6 or not?

I am sitting on the fence with Opencart at the moment. Zen is a good workable solution for me, but the overlong checkout process has always been the downfall of that application and is tedious for customers.

1.) no, they are more like 1.3.2 templates.
3.) That is a template issue is it not? ... I really would like to see a "update to ie7" to access full functionality button like they had years ago ... except M$ did it get you use their "ahem" browser.

oscommerce had a way to shorten the checkout so it would make sense that zen does too.
At the moment, opencart is at about the same length....

How do we shorten this?

Probably more than any other factor, the thing that really hacks people off with online shops is the checkout process. More so where that process is over long, asks for everything but your shoe size and your first sweetheart's name, or you get confused as to where you are now, or where you are going in the checkout process. Making it short, sweet and easy to understand needs to be the real goal.

Internet Explorer 6.0 usage, dependant on which figures you refer to, still accounts for around ten percent of browser usage. In the UK, official figures claim that 30 million people a day access the internet, so that is a potential of up to three MILLION folks still using IE6 in the UK alone.