New Design Discussion

Coordinator
Mar 6, 2009 at 5:26 AM
TEAM MEMBERS: In case you arne't logged in, there is a private discussion that can only be viewed when you are logged in regarding the design of RolyPoll (as mentioned in the source commit comments). Check it out plox* kthnxbai.


*Yes. Plox *is* in fact the stupidest way to say please in the entire world.  I know, I know, it is incredible.
Coordinator
Mar 7, 2009 at 1:42 AM
Am I responding to the wrong thing, or is this just a place to bring up design issues?

I can see us running into issues with multiple people working on the same thing without having any communication to know what each-other is thinking. I'll step back from the comments and let Lee finish them up, since I wasn't sure what I was doing in the first place.

Is there anything else we need to get working?
Coordinator
Mar 7, 2009 at 2:53 AM
It's fine to reply to this one. (Honest question: was the other discussion post even visible? I made it to where the world couldn't see it, but I'm not sure if I made it too private to where only I could see.)

I think it is possible to work together on many of the things we are working on. Like the comments, that was actually sort of working out okay going back and forth.   I didn't mean for it to look like I was stepping on any toes on my last commit, I just noticed - much like you did methinks - that our code behind files were becoming a little out of hand. At the time of all of our feature implementations, we were doing the simplest thing possible - throwing them into the single action, but this has turned out to be make things overly complex.  Like you said, I believe we need to start moving things out and giving them their own space. My comments in that commit notes and the discussions posts were not directly related to our work on the comments, they just happened to come to mind while I was working on patching things together. Perhaps I should have made the separation clear. I can see where it could sound like I was bitching at the commits prior to mine, but yeah. I wasn't. You got quite a bit wired up, which I am grateful for.


With the comments, there is only like one thing left to do - decide where the thing actually should post back to.  That brings up my design dilemma, because I want to start decoupling items much like you do.  That's why I didn't finish it last night, and that's what I think we need to discuss before we code much more. At least on the polls/votes/comments side, how do we want to break the items apart so the show action isn't some nasty bastard child of a state machine?

I have to work on the friends thing, which I think I can break apart in such a way that we can work on it together.  I have a feeling that breaking these tasks apart like I envisioned before will be much faster than doing everything by ourselves. But first, of course, we gotta tackle the comments. I can see the same messy actions showing up in the friends/profiles, which is why I'm interested in making some design choices now.


Coordinator
Mar 7, 2009 at 3:05 AM
Also, as we brain storm here, we can start building some work items in the issue tracker and assign them between us as we flesh it out. I think part of the difficulty we are finding in working on certain things is our not actually organizing what we are doing. I'm more to blame for this than anyone, but it's never to late to fix it.
Coordinator
Mar 7, 2009 at 5:07 AM
Edited Mar 7, 2009 at 5:10 AM

I'm more to blame for this than anyone, but it's never to late to fix it.

No need for your own public flogging here. You're productive and we've made good progress despite ASP shortfalls.

Regarding the design structure of things, and this is a very high-level, abstract, not-too-technical way of describing what I think we're talking about:
Separate our files to match a function for an object/idea, just like our best example so far is the /users folder. Personally, I think my kinda-sorta /admin folder breaks the paradigm slightly... Oops.

So if we work on our polls\show.aspx page where we have the basic "Here's my poll. Tada!" functionality and then use the control for polls to build a dynamically created "graph" and "vote" and "friends" sub-regions, we could benefit there. *** I don't think that last one made sense. You guys are the custom controls/content area masters. Passing out now. ***

Coordinator
Mar 7, 2009 at 4:30 PM
I'm not sure of the best design philosophy here. I broke out the showing of the polls into a page that accepts a "form" request and can decide whether it is showing "My Polls" or a single poll for now, and I guess more could be added. Though this does turn out to look like a really crazy state machine as you add more features.

Is the best philosophy to have separate pages for these things? Like a MyPolls.aspx, Poll.aspx, FriendPolls.aspx, etc. I would be opposed to that way of doing it either. I think the custom controls make doing it this way fairly easy, and it probably simplified the postbacks and redirects.

My thought on the comment control was that it could create the comment, and then just reload the page. That way the comment would just appear on whatever page you were working on if it was loading them from the DB. That may or not be possible as I haven't tried it, but that was my thought.
Coordinator
Mar 7, 2009 at 5:23 PM
Yeah, in the user's eyes, the comment should be created and reload the same page, but where does it post to on the back end? We can't simply check for postback in the control (as far as I could tell - I couldn't make it work anyway).  If we have it postback to the same form page, then we will have multiple forms posting to the same action, and we need to make sure what is what before we start committing to the database.  This can work, and it might be the only simple solution for now, but I have this strange feeling there might be a better way.  Also, won't comments only be available on an actual individual show page?

As for overall design, here is kinda what I had originally envisioned, I think. Please do move, hack, like, and hate parts as you see fit.  On this front, collaboration will result in a much better design.  

We have 4 main instances where we need to show a poll. We'd like to be able to see our own polls, we'd like to see all the polls from a particular friend, we'd need to be able to see all the polls all of our friends have recently created, and we'd want to be able to click and view a specific poll.

polls/show.aspx OR poll.aspx :   shows an individual poll. That's it. We'd need to handle voting and commenting here, whether it be with custom actions or some RESTful actions elsewhere. Whatever.

users/profile.aspx OR user.aspx : Profile information about a person (ours is pretty basic). Option to add/remove friendship.  Will also show public polls for this user. If the currently logged in user is this person's friend, it will also show any private polls (once that is implemented).

As for the naming of the next two, I'm torn.  Like, I don't think the page that shows my own polls needs to be much different (if at all) between the page my friends see at user.aspx.  For example, to view my recent posts on Twitter or Friendfeed, I'm shown the same page as someone who just visits my profile.  Things like deleting polls (if we allow it) would be controlled at the custom-control level.

Viewing Friends' recent polls. Hmm. This should be incorporated into the default page for authorized users.  So, whenever I login to RolyPoll, I'm taken to a dashboard that might give me an option to start a new poll, results from my latest poll, and a list of recent polls my friends have created.  I really don't need to see a list of recent polls from all my friends anywhere else. We might choose to have this page paginated (or have a control that paginates with AJAX, but that might be a later thing).

In short, I think separate things are the best way for it, the issue is just making sure we separate it in logical way that makes sense to users.  Actions within the pages can be separated out even further, as long as it is invisible to the user.

Custom controls are definitely going to make this process much easier. 
Coordinator
Mar 9, 2009 at 3:19 AM
So, as I mentioned in that email, I made another branch to play with. The reason was that the things I wanted to play with would have been *way* too many and *way* too drastic to perform on the main trunk.

Much of it is the same for now, much of it is drastically different, and some of it uses some features we've not used before.
I'd like to stress again that the current branch we've all been working on is the official branch. Any actual feature work needs to be done in there. If you see something you want to change in this new trunk, please do - but do so knowing this branch might never see the light of day. It's a playground, if you will.

However, if you look at the new code, there are a few things I'd like you to notice that might prove helpful.
  • .ASHX Handlers. By posting back to these with our forms, we can move a lot of code out of the view controllers that really clutters it up.  Furthermore, by having a dedicated endpoint for a specific action, it makes it much easier if we need to have device-specific pages do the same thing.
  • 960.gs Grid system. The most drastic change is the layout, because I have moved it off of the custom layout and over to a grid system framework. It is very similar to the Yahoo library, but much easier to use. You can read about it at http://960.gs and see it in action on the Rebase trunk. Me using this is the primary reason I wanted to keep the two branches separate: I wanted to see how quickly a clean layout could be thrown together with such a system.  Doing so on the main branch would have undone everything Eric did, which I didn't want to do.
  • Registered User Controls. We are creating a lot of user controls, and we end up trying to add them all the same way: LoadControl, Add to a panel.  There is an easier way for the time we want to have a one-off use of a panel.  By registering the control in the Web.config file, we can use it like we use regular ASP.net controls, like this <rolypoll:UserBlock ... /> or <rolypoll:CreateComment ... />. You can see these in action on the Show page and the RebaseContent master page.
I've got other somewhat "new" things that are in there, but either they aren't big enough to make a bullet point for or they aren't really complete yet. Check the commit history comments to see other stuffs.


Coordinator
Mar 9, 2009 at 5:05 PM
Well I looked over the new branch and I think I like it.

Overall the functional items seem pretty easy to grasp and are quite a bit more modular (simpler at least) than what we're already doing. I didn't check out any of the visual stuff because I don't care about it, but I can see the potential. I see no reason not to go ahead and use the handlers in the main branch....plus I couldn't get comments working so I might as well try them.
Coordinator
Mar 9, 2009 at 6:36 PM
I do like handlers, I think.  I'm going to do a bit more research on them later to see about detecting the request type (html, js, or xml) from within them.  The button that creates a comment is using a javascript postback, so it might not be too much more effort to have the handler return a javascript response that can be handled by the form, letting us update the page without refresh all ajax-style.  A similar effect could be created with the Vote button.

Although, interestingly enough, the redirect in the dev environment after Comment creation is so fast I can't tell if it is actually redirecting and refreshing or just refreshing the server side <form> element (ie: ajax already built in). But I didn't really care to look at enough to tell, either.

But I've used up all the free time I'd allocated to that side project for the next day or so, so I'll be stepping back into the main branch this afternoon.  Over the next 24-36 hours, expect the following updates:

Completed users/profile page
Work on RolyPoll home page (making it useful, informative)

Once these things are done (along with some client work I've been procrastinating on), I'll start implementing a few other things I had in mind in the test branch.


Coordinator
Mar 11, 2009 at 10:10 PM
Edited Mar 11, 2009 at 10:11 PM
I just figured out that we're doing stuff on CodePlex again.  Gavin has mentioned it to me but I had forgotten.  Also, I'm not sure if I got the email that Lee sent.  I still need to read over most of this topic but I glanced over the new branch and most of it looks pretty straightforward.  I hadn't read that much about HttpHandlers but it looks like they'll work nicely (and give me something to read this afternoon).

One of the things I'd been working on and was going to continue working on over break was the ShowPoll user control.  It looks like we're still using it?  CodePlex is having issues right now so I can't double check right now.  Here were my general thoughts/goals with the ShowPoll control.
  • It is given a PollID when loaded and then shows that poll.  Pretty simple there, and I think that part is working.
  • When it loads a poll, that poll is in a form (done).  Currently it does not handle voting.  I'm guessing all that needs to be done is to wire up the submit button/image to:
    /handlers/vote.ashx?id=" + currentPoll.ID +"&key=" + pollOptionList.UniqueID
    • Eventually, I was hoping we could use AJAX so that a user could vote on all his available polls without ever having to leave the page he was on.
  • Since the results are already loaded when the poll is loaded, I was going to write a quick script to switch to the poll results.  This was one area I was going to ask about since it looks like we're going to create a ShowPollResults control.  There are a lot of different ways we can do this.  We can go with two controls and have the loading page check if a user has voted and either load the ShowPoll control or the ShowPollResults control. We could have the ShowPoll control call ShowPollResults whenever it needs to show results (my least favorite method).  I was going to just put the results in the ShowPoll control.  Then, if the user has voted, show only the results and if not, show the poll with a link to view the results.  Then if the user clicks on view results it would switch to the results with a link to go back to the poll.  That way the switch between poll and results could be handled for any poll on a page without the need to postback and reload.  Any thoughts?
Granted, this would all be a lot easier in ASP.NET 3.5 or with AJAX but that'll be a bridge to cross in the next iteration.  On a complete sidenote, I managed to checkout the database from the new branch so I could test some of the new stuff.  Now CodePlex's team server has gone down and I can't check it back in.  I'll keep trying later this evening.

[Edit: Wow...the wiki formatting stuff doesn't work in the discussion forum.  So much for including a code block as an example...]
Coordinator
Mar 12, 2009 at 1:22 AM
Sounds good. Make sure any actual work you want to stick goes directly into the Main branch. Due to the the drastic nature of some of the junk I was playing around with, I didn't want to change everything we'd been working on and say "Oh, hi y'all, here's RolyPoll."  Hence, the test branch. Nothing that is committed to it is actually guaranteed to go anywhere - it's a place to try weird stuff and show everyone before we make it so. I figured it would be easier to pull the things out we like and refactor them into our existing code. While the commits show, like, 12 or 13 hours of work, any of those features (other than switching to a grid system) can probably be brought over in around 10 minutes.  I do like the last option regarding ShowPoll. Being able to throw a ShowPoll object anywhere and have it automatically change itself depending on the situation (vote, no vote, not logged in) would be great.  

The Vote button is wired up in the test branch to a javascript postback (or it should have been, if I didn't forget to commit it), so that handler should be ready to pull right over. It doesn't display results right yet, but that we beyond the scope I was looking in to at the time.  However, was starting to come together nicely, so it should be a simple "bring the handler over and redirect where the button goes" thing.  But yeah, I think the most important thing would be the user control itself, and I like that idea of how to handle it. 
Coordinator
Mar 14, 2009 at 11:53 PM
Alright, I've been doing a lot of work with a local copy of the program.  I enabled AJAX in it started developing an AJAX enhanced version of the ShowPoll control just to see how hard it would be to get it working.  I didn't want to commit anything to the actual project because I'm not sure if each developer machine would need to also have the AJAX extensions installed.  In theory, I think that I can just copy the dlls to the bin folder and add the proper references and everything should be copacetic.  I've given this a shot on the RolyPoll rebase project so can someone without AJAX installed download it and see if it will build...then see if AJAXTest.aspx works properly? 

I'm a bit worried that when I added the references, it's going to save my local path to the dll files instead of a relative path.  If this works, I'll update the main branch and start integrating the new ShowPoll control. 
Coordinator
Mar 15, 2009 at 9:17 PM
The partial postback works.
Coordinator
Mar 15, 2009 at 10:45 PM
Awesome, I still have a bit of work to do on the new ShowPoll control but hopefully I can start adding stuff to the main branch later tonight.