It's fun. C++ vs Java is a topic I'd rather not debate. And IMHO, it's going to turn out better. Eh, but that's subjective, so we'll see. Regardless, you can use anyone you want. Still, I'll continue developing this one and making it better. If anything, we can borrow ideas from one another.
And the fact is that if I'm going to help, it has to be a language that is not Java -_- Besides, I want to help.
Uh, I never said we should debate C++ vs Java. I don't understand why you have extreme prejudices over anything you dislike, like apple or java. If you really wanted to help, then you would provide input for the current program, or help work on it, IMO. :-/
Anyway, I tried opening your program after installing those libraries, and I can't even open it because MSVCR100.dll is missing.
SMK: I haven't looked closely at the newest version of the donation app (btw, I updated the first post for you, you bum ), but so far the changes look good, except for the error message, "no dononation to update," and, "Error: Error: Invalid dollar amount"
Uh, I never said we should debate C++ vs Java. I don't understand why you have extreme prejudices over anything you dislike, like apple or java.
That's why I said I didn't want to discuss it I don't want to get into arguments and stuff.
Quote:
If you really wanted to help, then you would provide input for the current program, or help work on it, IMO. :-/
I think you know better on how what it requires & whatnot, so you're covering that front. And I don't want to help code anything that has to do with Java.
Quote:
Anyway, I tried opening your program after installing those libraries, and I can't even open it because MSVCR100.dll is missing.
That is pretty weird, since that file is supposed to install it.
Regarding the current app, I honestly find the GUI pretty confusing.
EDIT: I just tested. After installing the download at said link (run the installer!), the application runs fine. Tested on Windows 7 x86.
Uh... Mystery. You don't want to discuss it? You're coding an app to compete with the current app all because you don't like to work in Java yourself! What do you expect to happen!? If you wanted to code the app, you should have said something ages ago. Doing this now is disrespectful to the work SMK has already put into the project. Coding your app is not helping anyone. If anything, it will actually hinder the current project by diverting attention from the application which is indisputably more mature. You don't want to code in Java, that's fine. You don't want to offer suggestions to someone coding in Java, that's fine too. But whatever you do, quit being so pretentious. Thanks.
I don't want to discuss Java vs C++! I have nothing against discussing the actual marathon application. If anything, I would like to suggest interface change akin to my design. I find it much more natural. But that's my opinion, though. I can't say if others agree. I have utmost respect for SMK's app. Obviously he/she has put his/her soul into this, so I shoot it down.
I had no idea an app for donations could have helped. Had someone said so, I could have helped much earlier. But the situation is as it is now. However, you should know that the interface that I make and that SMK is making is entirely different. In such way, it is good. There is no "ultimate" interface. Now we have two interface to discuss and to look at. We can decide what is good/bad with both and improve one.
Finally... sorry, I have no idea what pretentious means. I can only assume it isn't good.
pretentious (n) - 2. Characterized by assumption of dignity or importance.
I'll shoot a screenshot for Mike and everyone else.
Honestly, the way you're handling it right now, it looks worse. What happens when one person makes two donations? How does the program look? I can't do it myself because you haven't implemented the Add button yet, but I can't imagine it looking good. Also, there's a tremendous amount of wasted horizontal space, and as a result you're using up lots of vertical space as well. It is going to be inconvenient to have to collapse and expand donators, and have to scroll up and down the entire list in this manner. Then there's Lots and Lots of Pop-ups to do one function (searching).
you can't seriously have seen this thread and have thought "oh my, this is a good idea, i'll do mine too. and if i'm lucky people will pick my app and SMK's work will have been for naught, even though he was first and everyone was quite content with what he was delivering."
do you honestly think this is a good thing? this was stated before, but couldn't you have asked prior to having started work on this? the way things are right now, you only look like wanting to steal somebody elses spotlight.
^ Ignores. Have already explained myself. Feel free to ignore every post if you disagree.
Quote from Rakuen:
Honestly, the way you're handling it right now, it looks worse. What happens when one person makes two donations? How does the program look? I can't do it myself because you haven't implemented the Add button yet, but I can't imagine it looking good.
My thoughts are to sum it up. Then you can view history to see how many bids that has actually been done.
Quote:
Also, there's a tremendous amount of wasted horizontal space, and as a result you're using up lots of vertical space as well. It is going to be inconvenient to have to collapse and expand donators, and have to scroll up and down the entire list in this manner.
Horizontal space I cannot really imagine (unless you keep a lot of dialogs up). Vertical space could be trimmed. I haven't bothered resizing it yet. But it could be resizable. That's the best for all, no? And regarding scroll up/down. How would you rather have it? A combobox, or a list, like in the Java app? To me, they look similar.
Quote:
Then there's Lots and Lots of Pop-ups to do one function (searching).
At the moment, there should be two. Add bid -> find -> enter your search details, click search -> choose your search result -> done. But I suppose that if there's just one result, it can automatically select it. Hmmm.
Here is another wip. I changed the categorization in the bid overview. It looks more like the Java app now. Much cleaner. This is a setup file. Should install everything and add a shortcut to the start-menu.
Actually, I got to work. The problem was downloading the 64-bit libraries (because I'm using windows 7 64-bit). I do have to agree with Rakuen, the way you're doing it does look worse (I haven't looked at the newest version). However, you're dodging the main point, which is why you're making this program in the first place when we already had one that worked just fine.
As for the main point: - Because I want to help. - Because I don't want to work with Java. - Because IMHO the Java GUI needs work. - Because I want something to do. - Because it gives several approaches to the problem. I show how I do. SMK shows how he/she do it. You pick what's best. Someone integrates it into the final app. For example, I find SMK's interface confusing. Basically, I am doing some mockups, if you will. Fully working mockups in the end, hopefully. Btw, I have drawn some design and whatnot from SDK's app. So don't say SDK's work has been for nothing. Screenie:
if you don't want to work with java why don't you just leave it alone and let other people do it? looks like there are already several people willing to help with this project without whining about the language used.
i'm sure you can find another way to help the with the site/marathon or if not, maybe next year.
That's your problem and it's not an acceptable answer. Incidentally, making suggestions does not require you to code anything in Java. At all.
Quote:
- Because IMHO the Java GUI needs work.
Yeah, it does need work. That's why we offer suggestions to him for what to improve.
Quote:
- Because I want something to do.
There's more useful uses of your time than attempting to fill a need that's already been filled. For example, you could suggest things to SMK.
Quote:
- Because it gives several approaches to the problem. I show how I do. SMK shows how he/she do it. You pick what's best. Someone integrates it into the final app. For example, I find SMK's interface confusing.
The only problem you've brought up is GUI design which only requires you to sketch a mock-up showing your proposed ideas, and that would be far quicker. Then you can submit it as a suggestion to SMK. If you haven't figured this out yet, the solution to everything is suggest it to SMK.
On that final note. Honest to god, that is even more confusing than the last iteration. Part of being a designer is understanding that what is logical to you is not necessarily logical to everyone else. You can keep adding things to your version of the application, but it's never going to change the root problem, which is your proposed GUI. Seeing as that's why you started making the application in the first place... it's not looking good for you.
if you don't want to work with java why don't you just leave it alone and let other people do it? looks like there are already several people willing to help with this project without whining about the language used.
i'm sure you can find another way to help the with the site/marathon or if not, maybe next year.
Again, I haven't whined -_- I simply don't want to code Java. That's why I said I didn't want to discuss it! Yeah, I can always make something for next year. Or the next event. I'll just develop this for the next event or something else. And as a base for suggestions for SMK.
Quote from Rakuen:
Then help SMK by suggesting things to him. Yeah, it does need work. That's why we offer suggestions to him for what to improve. There's more useful uses of your time than attempting to fill a need that's already been filled. For example, you could suggest things to SMK. The only problem you've brought up is GUI design which only requires you to sketch a mock-up showing your proposed ideas, and that would be far quicker. Then you can submit it as a suggestion to SMK. If you haven't figured this out yet, the solution to everything is suggest it to SMK.
See my current wips as suggestions. Suggestions to SMK. Use it as a template for the work on the donation app.
Quote:
On that final note. Honest to god, that is even more confusing than the last iteration. Part of being a designer is understanding that what is logical to you is not necessarily logical to everyone else. You can keep adding things to your version of the application, but it's never going to change the root problem, which is your proposed GUI. Seeing as that's why you started making the application in the first place... it's not looking good for you.
And that is why feedback is needed. I don't know how you're taking donations or what you need or how. But it makes "sense" to me to organize them in some way. This way is similar to how SMK's app is currently Is there some other way that would be better? If so, out with it. It would help improve SMK's app, as well.
Yes. The better way to do it is the way SMK has implemented it. Seriously. All information for a donation is on a single line, and they're grouped together by donor. All bid option information on a single line, and again, it's grouped together by the master bid. Intuitive contextual selection for everything. We don't need to suggest things to you to make your app's GUI better because it's already been done. SMK's design could use some improvements, but we're suggesting them. There is absolutely no need to develop a second app.
What is so hard to understand about this? I'm trying to be nice and reasonable, but you are rapidly diminishing my patience.
It looks like there are two tabs: one that sorts by donor and that sorts by category. So it's probably a good idea to be able to view the list by category first and donor first. And a category would what the bid is for. Eg name a character. The question is, should a subcategory be necessary? Such as category = name character, subcategory = name of character. And you like a single-line information layout better than multi-line. I see. I will take that into account and see what I can come up with (mockup GUIs are good!).
I'm also trying to put up with you, so we're square on that.
OK, so maybe we got off on the wrong foot. If anyone feels like they need an apology, then I'm sorry. No hard feelings, right? So let's leave the second donation app's future behind us for now and concentrate on SDK's app and to make sure that this year's marathon is the best marathon ever without technical difficulties or problems, right? I'll make GUI concept sketches for SDK's app and analyze some behavior and code.
Right then, I guess the key here is to make one's intentions explicit. No point dwelling on it.
Also I've been unresponsive these past two days due to being busy with life related things, which have hopefully been sorted out.
Anyways, at this point I think a good idea would be to list/prioritize what needs to be fixed/implemented/changed.
For example, updating the error messages to be more human-friendly was pretty high on everyone's list, and so I decided to get to that as soon as possible. Conversely, I spent some time today trying to improve the search heuristic today (didn't get too far), but I don't think that it necessarily needs to be improved at this point, at least as compared to other things.
In my view, probably the biggest issue is the prize allocation/filtering jumble that exists right now. Basically, I think its because there's way too much going on in that one screen, but I think the bigger problem is that I don't really know what was involved in prize allocation last year, which means that whatever you see was me pulling stuff out of my ass. I'm assuming that one would pick a random donor who had donated within a specific time-frame, but were there any other kinds of ways of deciding who the prize went to that were used, or, more importantly, that people wanted to use but could not because it would be too complex to do by hand?