I've been working on a version of PHPGiftRegistry - sort of. My Wife's birthday just passed and we dusted off the gift registry to take a look at what she was interested in. It got me interested in working on it again, so I have been.
I skipped trying to do much with my current installation. I've started writing from scratch. I've separated the front-end user interface from the server-side SQL and processing. This lends to easier upgrades, easier branching, and easier merging. I've done my best to construct it in a solid, object-oriented fashion. Essentially what I've kept from the current project is the SQL Queries and the Database structure.
I expect to have a fairly close, feature-matched version finished in about a week. My question for people interested here is: Should I add it as a branch, or simply start another project as a derivative? Moving to the new version will be easy enough for anyone choosing to upgrade.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, by now you've all noticed that I haven't revealed my grand update to giftRegistry. Though I'd like to, I got hit by a couple of big distractions. FWIW, I'm not done or giving up. It looks like most people would prefer to see this as a new project. I'm curious to see reasons, but you don't have to have one.
More to come, I promise
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that the main reason is because you started writing from scratch. By separating the two projects, you and generalpf can head in opposite directions if it comes down to it, and offer two distinct options to fill the gift registry demand.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-10-31
There are only a few good and working open source Wishlist apps out there. So having an additional one would be a benefit. Another pro for creating an additional project would be, that I am currently not able to get in contect with generalpf to get reviewed my multilanguage changes. I think it would be also possible to make your new app multilanguage if it is not already done and if you like it of course.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be great if we could get generalpf's view. I can see value in both branching and forking. But if generalpf is willing to hand over the reins, so to speak, then I would prefer to branch with the assumption that aeiche's branch would become trunk once it is feature-matches the current trunk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, Sorry on the delay. I had a bit of an avalanche of things happen in real life that have prevented me from making a lot of progress on my version. That said, I get the impression that people are interested more in a fork than a branch. It makes sense as a branch implies utilizing the existing code. I will continue to press forth. When I have a closer feature-matched version, I'll post here to let people know what's going on.
Ideally, I'd like to have it up in a week, but again, life gets in the way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me know if you need any help with the UI design
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-11-11
Are you plan to use some JavaScript/Ajax stuff or wild it be plain old HTML like phpgiftreg is already? I think there are a lot of improvements possible looking at phpgiftreg.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About a month and a half ago, my job disappeared. Since that happened, most of my time has been invested in finding a new job (which I've done, yay!) and doing a lot of programming into a side-business I've been working on (which has also been picking up steam).
So unfortunately, the new giftreg has taken a back seat to all of this. To pile more onto my plate, I've been using jQuery a lot more recently and I'm very tempted to rewrite all the javascript stuff using it instead of Prototype - and even then to setup two versions which would allow you to change out libraries (how crazy is that)
Now that things are calming down a little bit, I think I can finally get going on it again. I opened the project for the first time in a month last night. (It helps that my family has been using the system and I'm seeing all the things I don't like about it)
I do honestly think that I can get the new version finished a couple of weeks before Christmas. My original target had been before thanksgiving to help with Black Friday, but that has come and gone obviously. I'm uncertain of being feature matched by then, but definitely I'll have the fundamental functionality down.
There were a couple of questions, and I'm sorry I didn't get to them before now:
phillyhotshots: Yes, UI design would be a big plus (because I am not a designer) I will keep updates here for the moment, and let you know when I've forked the project so you can contribute. I'm planning on making this highly flexible HTML via CSS. So the basic HTML will remain the same, but will be very flexible with CSS.
sonicmstr: Right now the code is going to be extremely ajax/javascript. It just recently occurred to me that there might be reason to develop it to degrade gracefully and still work if javascript were turned off. However, that's not my main concern right now. My code currently provides for a single-page system (excluding the login/logout).
Additionally, this is designed to be eventually accessible as a service, so not only can we create different interfaces (for mobile devices, web browsers, etc.) but we could even in theory write iOS or Android Apps for it. That's a long way off, but I'm putting in the hooks now. :)
I'm pleased with the response from you guys, and I'm sorry there's been such a big delay. I'll do my best to get it usable, and then anyone who's interested can have at it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Congrats on the new job!! No need to apologize. We're not paying customers; this isn't - and shouldn't be - your first priority by any means.
I'm excited to see what you can do with it. Again, I'm not a programmer but I've heard great things about jQuery from my friends who all love it.
Any chance you'll be including or have some way of adding browser extensions for Chrome/Firefox/etc. or at least some kind of bookmarklet to make it easier to add things to the wishlist? The hardest thing right now is for my parents and in-laws adding things to their own lists. They've gotten the hang of reserving and purchasing things, but adding things to their own lists is "too hard". (Copying and pasting URLs, etc.)
Again, I'm excited to see what you can do and look forward to seeing/testing the new gift registry/wishlist! (Which reminds me: have you named it yet?)
/Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know if I'll be including browser extensions, if I do it'll be unfortunately somewhat low priority because the main goal is to get a feature matched browser-based version first. But, bookmarklet handlers provides a very cool feature that I hadn't thought of. Consider if you're on Amazon, Costco, B&N, Toys R' Us, whatever the website, and clicking on the one bookmarklet automatically parses the information and adds it to the list. That's brilliant! It'll definitely be possible (I don't know if I'll write them), and I hope to provide some good documentation to make it easy (not my strong suit though)
Ideally I'd like to take it a step further an throw in a barcode handler (still don't know how I'd do that), so if you're at the store, you take a picture of the barcode, send it over to the wishlist and it automatically sticks the item into the list. That would be super cool too.
I have not yet named it. I'm not particularly fond of PHPGiftReg (sorry Ryan), so I imagine it'll be something like dumb SuperWishlist, or GiftTracker. Any name suggestions would be very welcome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would a bookmarklet or browser extension share an API/RPC with mobile apps? I'm very interested in an Android app that can work with a web-based wishlist. A front end like ShopSavvy makes it very easy to scan a UPC. But they haven't caught on that ties to a web backend would really make it worthwhile. If I every get time I'll open up my Android SDK book and start coding.
As for a name what about Wisher/Wishr, Gifter/Giftr, WantIt, WishingWell. Names are not my strong suite either..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right now I'm envisioning the bookmarklet and apps going through the same web service, probably a simple REST interface: that way you just need to know the server, a username/pass, an action, and name/value pairs. I see this kind of solution being a broad-approach to all kinds of gift registrys. No longer do you need to register only at a couple of places for a wedding. Anyone with a smartphone can access your registry and buy what you want. Comparison shopping becomes super-easy, and matching barcodes allow you to buy something at another store for cheaper. Your phone, your computer, whatever. On top of that, the system can start to match common elements. If someone sees a nice blender, the system can tell them that someone's already bought a nice blender, Even if it's not the same kind. Same for Christmas and birthday wishlists.
I'm dreaming pretty big here, but I like the idea.
I do like WishingWell. At the moment, my best suggestion is WishlistPlus (or Wishlist+) I should get the name figured out so I can get the project it's own forum to talk on (with that, I can get feature requests and whatnot setup)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to ask something that's pretty important: do you plan on making it so we can import/migrate from PHPGiftReg? I guess that's kind of a deal-breaker. :) I don't think my users would go for having to re-do their lists and all that.
I don't know how you'd do that, though… are you still going to have "families"? I was never crazy about that, possibly because I didn't understand how to use it or make it work the way I needed it to.
/Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new system is being built around the current database structure, so it'll be a drop-in replacement. I briefly started working on my own DB system, but as generalpf already did a tremendous amount of work writing the queries and making it all work, I'm inclined to just use that.
The only change I have in mine at the moment DB wise is moving images to their own table. I'd like to make it possible to add more than one image to an item.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Awesome! I don't know why, but for some reason it just hit me this morning when I was thinking about it, and I got worried. :)
(I guess that's what you meant by separating the front-side GUI from the back-end.)
/Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-12-12
I like the name Wishlist+ it is easy to remember and explains in short what this app is about. Alternatively I would suggest a acronym like WOIP (Wish Organizer in PHP), Wophy (Wish Organizer PHP Hypertext Preprocessor) or similar. So I am curious about the new project site.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
aeiche, that is great news that you are adding to this project! My family has used it for the past couple years and it's by far the best script out there, Two suggestions/features that would make this better are:
(1) Do away with families and instead add people by searching for them by name or email. My wife and I use this with our parents who are all divorced and remarried. That's 4 families right there. They all use the site with their other families, which adds 4 more to the mix, for a total of 8 families. With over 40 people using the site, it's ridiculous to have to manage the families, and we've tried using one default family, but then you end up with a list of 30 people you're not shopping for. It'd be so much easier to just search for whomever you want…. the way social network sites do it.
(2) The ability to add suggestions to a person's list. For instance, if I buy my son a Kinect, it'd be a cool feature to be able to tell others shopping for him that they could buy accessories/games for it. Another use would be if you bought something that's not on their list, you could add it and cross it out so that everyone knows not to get it. Most importantly, the main benefit is that I have people creating multiple accounts (one for themself, one for their spouse), so that they can create a wishlist for them. I have to deny the requests and tell them to just add the items to their own list and add their partner's name in front so people know it's not for them.
As does everyone else, I have many other suggestions… although these two I feel are important. Good luck with your project, can't wait to use it!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like both of johnnyseb's ideas! I definitely don't like the current "families" setup and would much prefer a simple search by name or e-mail (and maybe even a per-user option where people could make themselves only available via e-mail search if so desired, but that's not critical). The families thing just doesn't work for me, same as johnnyseb described.
Idea #2 sounds good to me, too. :) I know that one (or similar) was suggested before and Ryan (generalpf) did not want that option added and thus had no plans on adding it. (His thoughts were that the whole point of a wishlist is that you put down what you want, and letting/encouraging people to buy other things defeated the purpose. I see his point, but I still think it's a good option/feature.)
/Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree, that removing families is the right way to go. I think a "browse" feature which could be switched on or off would be good, as well as a search function. I likewise started to get frustrated with the families. My immediate family exchanges gifts with everyone in the group. I give to my brother, sister, and parents. My Wife's family and my extended family exchange on a one-to-one basis. Each person gives to only one individual. It's obnoxious to have to include an entire family to get just one person. My only hesitation in making this change is that I want the system to be drop in compatible. I believe this would require a database change. Once I have a solid version, I will absolutely look deeper at this.
#2 is definitely on my list. Not only suggestions but also adding an item that you bought, so if you purchased a Kinect and it wasn't on his list, someone won't make the mistake of purchasing a second one. I think I'd include the option to make the user aware of an item addition or not. You can make suggestions to a user, or just buy something for them. Obviously it always keeps them in the dark about whether or not the item is purchased, and a user could reject whether or not they want something on their list.
"But Aaron, where is it?"
Yea yeah, I know. I've expected to have something done and ready to go, and it's not quite there yet. Right now, this is what I've got in my new version:
Your list
Other's lists
Add/edit/delete items from list
Mark reserved/released.
That's a lot, but it's not. I have no admin stuff setup, which is a big deal. I'm looking to put this up on either Google's code host, or possibly simply hosting it on my website (just for the sake of doing it). I'm leaning towards Google because they have features. The only reason for moving away from sourceforge is that the interface is crowded, and non-obvious IMO. I will of course post here when I have something for everyone to download.
The advantage will be, when you set this up, you can just stick it in another directory and give the proper DB connection info. If something doesn't work the way you want it to, you can always go back to your old install with absolutely no changes.
We're about to hit Christmas, which means I probably won't have this finished in time, but it'll be there for next Christmas!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been working on a version of PHPGiftRegistry - sort of. My Wife's birthday just passed and we dusted off the gift registry to take a look at what she was interested in. It got me interested in working on it again, so I have been.
I skipped trying to do much with my current installation. I've started writing from scratch. I've separated the front-end user interface from the server-side SQL and processing. This lends to easier upgrades, easier branching, and easier merging. I've done my best to construct it in a solid, object-oriented fashion. Essentially what I've kept from the current project is the SQL Queries and the Database structure.
I expect to have a fairly close, feature-matched version finished in about a week. My question for people interested here is: Should I add it as a branch, or simply start another project as a derivative? Moving to the new version will be easy enough for anyone choosing to upgrade.
I'm not a programmer, but my vote is to just start it as a new project.
/Kevin
I second the notion to start as a new project
I love to see the progress of this project.
Well, by now you've all noticed that I haven't revealed my grand update to giftRegistry. Though I'd like to, I got hit by a couple of big distractions. FWIW, I'm not done or giving up. It looks like most people would prefer to see this as a new project. I'm curious to see reasons, but you don't have to have one.
More to come, I promise
I think that the main reason is because you started writing from scratch. By separating the two projects, you and generalpf can head in opposite directions if it comes down to it, and offer two distinct options to fill the gift registry demand.
There are only a few good and working open source Wishlist apps out there. So having an additional one would be a benefit. Another pro for creating an additional project would be, that I am currently not able to get in contect with generalpf to get reviewed my multilanguage changes. I think it would be also possible to make your new app multilanguage if it is not already done and if you like it of course.
It would be great if we could get generalpf's view. I can see value in both branching and forking. But if generalpf is willing to hand over the reins, so to speak, then I would prefer to branch with the assumption that aeiche's branch would become trunk once it is feature-matches the current trunk.
now would be a good time to launch, with Christmas around the corner.
Yeah, Sorry on the delay. I had a bit of an avalanche of things happen in real life that have prevented me from making a lot of progress on my version. That said, I get the impression that people are interested more in a fork than a branch. It makes sense as a branch implies utilizing the existing code. I will continue to press forth. When I have a closer feature-matched version, I'll post here to let people know what's going on.
Ideally, I'd like to have it up in a week, but again, life gets in the way.
Let me know if you need any help with the UI design
Are you plan to use some JavaScript/Ajax stuff or wild it be plain old HTML like phpgiftreg is already? I think there are a lot of improvements possible looking at phpgiftreg.
Any updates, Aaron? (I know, I'm sure you'd post here if you had anything, but I can't help but ask.)
/Kevin
Tragically, no.
About a month and a half ago, my job disappeared. Since that happened, most of my time has been invested in finding a new job (which I've done, yay!) and doing a lot of programming into a side-business I've been working on (which has also been picking up steam).
So unfortunately, the new giftreg has taken a back seat to all of this. To pile more onto my plate, I've been using jQuery a lot more recently and I'm very tempted to rewrite all the javascript stuff using it instead of Prototype - and even then to setup two versions which would allow you to change out libraries (how crazy is that)
Now that things are calming down a little bit, I think I can finally get going on it again. I opened the project for the first time in a month last night. (It helps that my family has been using the system and I'm seeing all the things I don't like about it)
I do honestly think that I can get the new version finished a couple of weeks before Christmas. My original target had been before thanksgiving to help with Black Friday, but that has come and gone obviously. I'm uncertain of being feature matched by then, but definitely I'll have the fundamental functionality down.
There were a couple of questions, and I'm sorry I didn't get to them before now:
phillyhotshots: Yes, UI design would be a big plus (because I am not a designer) I will keep updates here for the moment, and let you know when I've forked the project so you can contribute. I'm planning on making this highly flexible HTML via CSS. So the basic HTML will remain the same, but will be very flexible with CSS.
sonicmstr: Right now the code is going to be extremely ajax/javascript. It just recently occurred to me that there might be reason to develop it to degrade gracefully and still work if javascript were turned off. However, that's not my main concern right now. My code currently provides for a single-page system (excluding the login/logout).
Additionally, this is designed to be eventually accessible as a service, so not only can we create different interfaces (for mobile devices, web browsers, etc.) but we could even in theory write iOS or Android Apps for it. That's a long way off, but I'm putting in the hooks now. :)
I'm pleased with the response from you guys, and I'm sorry there's been such a big delay. I'll do my best to get it usable, and then anyone who's interested can have at it.
Congrats on the new job!! No need to apologize. We're not paying customers; this isn't - and shouldn't be - your first priority by any means.
I'm excited to see what you can do with it. Again, I'm not a programmer but I've heard great things about jQuery from my friends who all love it.
Any chance you'll be including or have some way of adding browser extensions for Chrome/Firefox/etc. or at least some kind of bookmarklet to make it easier to add things to the wishlist? The hardest thing right now is for my parents and in-laws adding things to their own lists. They've gotten the hang of reserving and purchasing things, but adding things to their own lists is "too hard". (Copying and pasting URLs, etc.)
Again, I'm excited to see what you can do and look forward to seeing/testing the new gift registry/wishlist! (Which reminds me: have you named it yet?)
/Kevin
Thanks!
I don't know if I'll be including browser extensions, if I do it'll be unfortunately somewhat low priority because the main goal is to get a feature matched browser-based version first. But, bookmarklet handlers provides a very cool feature that I hadn't thought of. Consider if you're on Amazon, Costco, B&N, Toys R' Us, whatever the website, and clicking on the one bookmarklet automatically parses the information and adds it to the list. That's brilliant! It'll definitely be possible (I don't know if I'll write them), and I hope to provide some good documentation to make it easy (not my strong suit though)
Ideally I'd like to take it a step further an throw in a barcode handler (still don't know how I'd do that), so if you're at the store, you take a picture of the barcode, send it over to the wishlist and it automatically sticks the item into the list. That would be super cool too.
I have not yet named it. I'm not particularly fond of PHPGiftReg (sorry Ryan), so I imagine it'll be something like dumb SuperWishlist, or GiftTracker. Any name suggestions would be very welcome.
Would a bookmarklet or browser extension share an API/RPC with mobile apps? I'm very interested in an Android app that can work with a web-based wishlist. A front end like ShopSavvy makes it very easy to scan a UPC. But they haven't caught on that ties to a web backend would really make it worthwhile. If I every get time I'll open up my Android SDK book and start coding.
As for a name what about Wisher/Wishr, Gifter/Giftr, WantIt, WishingWell. Names are not my strong suite either..
Right now I'm envisioning the bookmarklet and apps going through the same web service, probably a simple REST interface: that way you just need to know the server, a username/pass, an action, and name/value pairs. I see this kind of solution being a broad-approach to all kinds of gift registrys. No longer do you need to register only at a couple of places for a wedding. Anyone with a smartphone can access your registry and buy what you want. Comparison shopping becomes super-easy, and matching barcodes allow you to buy something at another store for cheaper. Your phone, your computer, whatever. On top of that, the system can start to match common elements. If someone sees a nice blender, the system can tell them that someone's already bought a nice blender, Even if it's not the same kind. Same for Christmas and birthday wishlists.
I'm dreaming pretty big here, but I like the idea.
I do like WishingWell. At the moment, my best suggestion is WishlistPlus (or Wishlist+) I should get the name figured out so I can get the project it's own forum to talk on (with that, I can get feature requests and whatnot setup)
I forgot to ask something that's pretty important: do you plan on making it so we can import/migrate from PHPGiftReg? I guess that's kind of a deal-breaker. :) I don't think my users would go for having to re-do their lists and all that.
I don't know how you'd do that, though… are you still going to have "families"? I was never crazy about that, possibly because I didn't understand how to use it or make it work the way I needed it to.
/Kevin
The new system is being built around the current database structure, so it'll be a drop-in replacement. I briefly started working on my own DB system, but as generalpf already did a tremendous amount of work writing the queries and making it all work, I'm inclined to just use that.
The only change I have in mine at the moment DB wise is moving images to their own table. I'd like to make it possible to add more than one image to an item.
Awesome! I don't know why, but for some reason it just hit me this morning when I was thinking about it, and I got worried. :)
(I guess that's what you meant by separating the front-side GUI from the back-end.)
/Kevin
I like the name Wishlist+ it is easy to remember and explains in short what this app is about. Alternatively I would suggest a acronym like WOIP (Wish Organizer in PHP), Wophy (Wish Organizer PHP Hypertext Preprocessor) or similar. So I am curious about the new project site.
aeiche, that is great news that you are adding to this project! My family has used it for the past couple years and it's by far the best script out there, Two suggestions/features that would make this better are:
(1) Do away with families and instead add people by searching for them by name or email. My wife and I use this with our parents who are all divorced and remarried. That's 4 families right there. They all use the site with their other families, which adds 4 more to the mix, for a total of 8 families. With over 40 people using the site, it's ridiculous to have to manage the families, and we've tried using one default family, but then you end up with a list of 30 people you're not shopping for. It'd be so much easier to just search for whomever you want…. the way social network sites do it.
(2) The ability to add suggestions to a person's list. For instance, if I buy my son a Kinect, it'd be a cool feature to be able to tell others shopping for him that they could buy accessories/games for it. Another use would be if you bought something that's not on their list, you could add it and cross it out so that everyone knows not to get it. Most importantly, the main benefit is that I have people creating multiple accounts (one for themself, one for their spouse), so that they can create a wishlist for them. I have to deny the requests and tell them to just add the items to their own list and add their partner's name in front so people know it's not for them.
As does everyone else, I have many other suggestions… although these two I feel are important. Good luck with your project, can't wait to use it!
I like both of johnnyseb's ideas! I definitely don't like the current "families" setup and would much prefer a simple search by name or e-mail (and maybe even a per-user option where people could make themselves only available via e-mail search if so desired, but that's not critical). The families thing just doesn't work for me, same as johnnyseb described.
Idea #2 sounds good to me, too. :) I know that one (or similar) was suggested before and Ryan (generalpf) did not want that option added and thus had no plans on adding it. (His thoughts were that the whole point of a wishlist is that you put down what you want, and letting/encouraging people to buy other things defeated the purpose. I see his point, but I still think it's a good option/feature.)
/Kevin
Thanks for the suggestions johnnyseb,
I agree, that removing families is the right way to go. I think a "browse" feature which could be switched on or off would be good, as well as a search function. I likewise started to get frustrated with the families. My immediate family exchanges gifts with everyone in the group. I give to my brother, sister, and parents. My Wife's family and my extended family exchange on a one-to-one basis. Each person gives to only one individual. It's obnoxious to have to include an entire family to get just one person. My only hesitation in making this change is that I want the system to be drop in compatible. I believe this would require a database change. Once I have a solid version, I will absolutely look deeper at this.
#2 is definitely on my list. Not only suggestions but also adding an item that you bought, so if you purchased a Kinect and it wasn't on his list, someone won't make the mistake of purchasing a second one. I think I'd include the option to make the user aware of an item addition or not. You can make suggestions to a user, or just buy something for them. Obviously it always keeps them in the dark about whether or not the item is purchased, and a user could reject whether or not they want something on their list.
"But Aaron, where is it?"
Yea yeah, I know. I've expected to have something done and ready to go, and it's not quite there yet. Right now, this is what I've got in my new version:
Your list
Other's lists
Add/edit/delete items from list
Mark reserved/released.
That's a lot, but it's not. I have no admin stuff setup, which is a big deal. I'm looking to put this up on either Google's code host, or possibly simply hosting it on my website (just for the sake of doing it). I'm leaning towards Google because they have features. The only reason for moving away from sourceforge is that the interface is crowded, and non-obvious IMO. I will of course post here when I have something for everyone to download.
The advantage will be, when you set this up, you can just stick it in another directory and give the proper DB connection info. If something doesn't work the way you want it to, you can always go back to your old install with absolutely no changes.
We're about to hit Christmas, which means I probably won't have this finished in time, but it'll be there for next Christmas!