Page 18 of 27

Posted: Sun Sep 24, 2006 5:20 pm
by feyd
astions wrote:Do we have a list anywhere of things we need to do?
I believe onion and/or Jenk were working on such a list.

Posted: Sun Sep 24, 2006 5:36 pm
by neophyte

Posted: Sun Sep 24, 2006 6:27 pm
by Jenk
My Gentoo install is almost settled after much hairloss and pains in the neck, just got to work out how to add the php eclipse plugin. So ja.. I'm pretty much as ready as I'll ever be. (I completely removed windows - after accidentally wiping and entire 250gb disk :|)

Will see about furthering my use case diagram, though in all honesty.. every time I try it turns into a mish-mash of use case and process flow diagram :/

Posted: Mon Sep 25, 2006 2:05 am
by nickvd
astions wrote:That would actually be classified as a seperate project. Gallery 2 uses a similar program for uploading images. Anything that helps the end user create product listings efficiently is a good thing.
I use G2 extensively, and alot of my clients rely heavily on the Gallery Uploader, I even had a site setup where gallery had a zencart module installed. Every time an image was added it got copied over to zencart. It was done to "simulate" a direct to zc uploader, and worked okay until compatibility of the g2 mod with current (and secure) versions :(

I may even be willing to take a crack at it, I've done some kicking the tires with the couple different phpGUI packages in the past and have always wanted to find a decent project to use them for...

Posted: Mon Sep 25, 2006 5:10 am
by onion2k
The biggest advantage of a GUI interface to the shop I can see would be some sort of 'spreadsheet' affair that would allow admin to import a CSV/XML/Excel file of products, tidy them up, and then upload them directly to their shop database. Controling minor things like welcome pages and simple settings would be a bit pointless as that could just as easily be achieved in an online environment.

Posted: Mon Sep 25, 2006 12:00 pm
by nickvd
onion2k wrote:The biggest advantage of a GUI interface to the shop I can see would be some sort of 'spreadsheet' affair that would allow admin to import a CSV/XML/Excel file of products, tidy them up, and then upload them directly to their shop database. Controling minor things like welcome pages and simple settings would be a bit pointless as that could just as easily be achieved in an online environment.
Agreed... The Gallery Uploader IMHO should be used as a good baseline for the app... While it does let you add categories (albums), it's primary focus is to allow importing of many many images at the same time (each with their available comments/descriptions) and the interface for the shop should be limited to the same abilities, or even strictly to product import, either from a data source like xml/csv/excel or manually adding them from within the app itself (i.e a Wizard-like option)

<edit>
After thinking a little bit about this, I'm leaning towards strongly recommending the gui tool (released at the same time/seperatly i dont know). I can forsee the app easing some major imports that would otherwise prevent some shop owners from using the shop.
For Example:

"I dont even have a website or an online shop, but I do use myob/simply accounting/etc to run my widget store. I want to start a website to sell them, but I dont have the time or the effort to add my 10,000 different items. I'd love to be able to export my inventory from my database and easily import them into a shopping cart, right from the desktop. I don't care about a web interface, that web stuff is beyond me. Besides, my webguy will be handling all the interweb stuff for me."
</edit>

Posted: Mon Sep 25, 2006 2:10 pm
by Jenk
Just to remind people.. we need an apllication to administer before we can use an administration application on it.

Hint: Let's leave the desktop gui for later.

Posted: Mon Sep 25, 2006 6:47 pm
by DrTom
Pretty good point Jenk.

But in regards to the desktop GUI, it's a pretty cool idea nad if done properly could really make things a lot easier.

Although, to whoever said using php GUI stuff, I'd recommend against this, as they require PHP and that's a much more
major install than installing the libraries necessary to do something in C++/Java/C#/Anything really. Not to mention most of
the PHP graphics libs are severely lacking, especially in documentation. I've messed with a few different ones, and quite frankly,
they're just not practical to use for any sizeable application. Anyway, thats just my opinion on the matter. With that said,
we should most certainly be focusing our attention on the actual store as it's hard to admin a store before it exists

Posted: Tue Sep 26, 2006 6:03 am
by onion2k
The last change was made to the wiki almost a week ago. Is there a reason why people aren't contributing to the requirements pages?
What can we do to help you lot add things?

Posted: Tue Sep 26, 2006 3:00 pm
by ok
Hint: Let's leave the desktop gui for later.
We will wait until the entire shop will be ready for use via the web interface and then we'll add the "desktop gui" has a plug-in!

Posted: Tue Sep 26, 2006 4:24 pm
by Jenk
How about we just concentrate all this thought on the desktop app, on the design of the eCommerce application? :\

Like onion2k has mentioned we haven't had an update to the wiki for some time now. I could upload some more use case diags but in all honesty, they will hinder rather than help because even I, as the author, can tell they aren't right. :s

Posted: Tue Sep 26, 2006 4:35 pm
by Benjamin
This is why in my first post I mentioned that all volunteers should commit to x hours per month on the project. This way the project continues to move forward.

I'll be happy to add some things to the wiki and do whatever needs to be done, but I need something like a TODO list to work from. Otherwise I'm really in the dark about what needs to be done.

Posted: Wed Sep 27, 2006 4:35 am
by sike
hey guys,

i just cleaned the frontpage a bit. moved the requirements stuff to its own page - hope thats ok for all of you

cheers
Chris

Posted: Wed Sep 27, 2006 4:40 am
by sike
astions wrote:This is why in my first post I mentioned that all volunteers should commit to x hours per month on the project. This way the project continues to move forward.

I'll be happy to add some things to the wiki and do whatever needs to be done, but I need something like a TODO list to work from. Otherwise I'm really in the dark about what needs to be done.
hey astions,

i think implementing a todo list would be a good thing to start then (: as you might have noticed i moved the requirements stuff off of the mainpage. the next step could be reading through all of them and compile a todo list. some requirements are described in reasonable detail while others have just a very general decription (e.g. User templates). i think it would help us all if someone tracks which requirements need some love (:

cheers
Chris

Posted: Wed Sep 27, 2006 5:02 am
by onion2k
Well, for the next week or so I suggest that out TODO list consists of:

1. Gather requirements for different sections and add them to the wiki.

Go to the wiki requirements page (nice one Sike), find a section that you think needs a particular feature, and add it. Brainstorm basically. Once we have a full set of features we can go through and tidy it up, and draw up a final requirements list from everything there. Then we can go through that list, write a specification, a data model, and an object model based on the requirements.

Remember to use the discussion pages if you agree/disagree with things people add.