Moving Forward

I'm moving on.  The decision with lists that I discussed before is over.  I made up my mind...for now.  I don't know for sure that it was the right decision, but it feels better than the other.  Plus, my passion and excitement for Idea was slowly fading because of my indecision.  Worse than making a bad decision is giving up, so I made a decision.

A list will no longer have a specific data type.  Every list will have its own set of fields.  For example, say I wanted a list of people, and I wanted each person to have a name and an age.  I could make two lists, one with the name and one with the age, but the names and ages wouldn't be bound to each other.  Instead, I'd make a list that had a name and an age in each item.

The issue with this approach is that while it simplifies some things, it complicates others.  I won't explain how, but it really changes the concept behind lists in Idea.  I'm going to have to do a bit of re-coding.  But it's better to re-code now than later.

Now, since each list will have multiple fields, the user will need to select one as sort of the title.  In other words, when the list isn't expanded out to show all fields, which single field does it show?  Also, I think Idea should not allow any duplicates within this field.  There has to be a field that sets it apart from the others.  Of course, it would only be unique within that individual list.  There can be another Idea of the same type with an identical list item.

I think it would be a good idea to apply this concept to the idea types as well.  For example, when searching for ideas, only the "title" field would show in the results.  This could be very handy.  Plus, making list items and ideas similar means I can reuse more code.  Very convenient for me.

Anyway, that's where I am now.  I would have started coding rather than writing this post, but the day is almost over and I don't have enough time to make a dent in the code, and I wanted to finish something!  Thanks for reading!

clevceo

Link Data 3

Unfortunately, I'm back to wondering again.  I thought of something last night that might throw a wrench in things.  Then again, it might make things really cool as well.

I realized that a user might want to create lists where each item contains more than one field.  For example, say you were creating a restaurant menu.  There is a list of items in the menu, each with a name and price (we'll pass on the description).  You could possibly create a separate idea for each item and just link them to the menu.  That was what I initially figured people would do.  However, what if the user wanted those items to be specific to that menu?  In other words, if the menu is deleted, they want the menu items deleted as well.  The items are literally a part of the menu.  My current method wouldn't allow that.

Then I realized that I could change my implementation of lists entirely.  Rather than a list having a specific data type, they will each have a link type I mentioned in previous posts, except that it will no longer be called a "link" type in this context.  Basically, lists will be lists of mini-ideas.

The average list will probably have only one field inside it's mini-idea type, in which case it will behave as it would if the list had a specific data type.  This way, if someone wanted to link to another idea, they could put an link field in the mini-idea type.  The confusing part about this is that they can add multiple link fields.  It wouldn't be too bad coding it under the hood, but creating an interface for that is beyond me at the moment.  I have to do alot of thinking.

That's where I'm at right now.  Thanks for reading!

clevceo

Link Data 2

I'm back and I think I finally know how I'm going to proceed.  However, I only just came to this verdict yesterday.  During my vacation, I thought long and hard about it and was very confused.  I actually became a bit discouraged, thinking that I might not be able to come to a solid decision.  From the beginning, I've wanted Idea's structure to be solid and logical.  I didn't want there to be anything left unsure about it.  Fortunately, we're still on track.

If you haven't read my previous post, I'll update you.  When ideas are linked to each other, the user will be able to attach some data to the links.  It won't be limited to a simple caption.  There can basically be an entire "idea" attached to it.  These will act similar to standalone ideas.  They will have a blueprint much like an idea type.

My dilemma had to do with how the blueprint was treated.  Were the blueprints to be standalone and reusable?  In other words, when you are creating a column in an idea type, would there be a list of link types to choose from?  Or would the user create the link data fields from scratch every time he created a link column?  I didn't know which method was best.

Yesterday, I stopped thinking like a programmer and decided to look at it from a user's perspective.  If a single link type was used in multiple different idea types, the user could get confused.  It would be much simpler to understand if each idea type was completely cohesive.  While making them reusable could be nifty and save a little time, it would add complexity.  Besides, creating the link types from scratch won't be too hard.

Long story short, creating them from scratch every time makes things more simple without removing any important functionality.  Now that I have made my decision, I can comfortably move forward.

Hopefully next time I post, I can say that I've completed this step.  Thanks for reading!

clevceo

Link Data

The columns are done.  The UI doesn't really look any different than it did in the last screenshot, but all of the textboxes, buttons, etc. actually work now.

So here I am, ready to start writing the link data.  However, I'm not ready.  I'm ready because I've tested and debugged everything up to this point and I can't progress any further until the link data code is written.  But I'm not ready because I'm not entirely sure yet how I want to do it.

If you don't know what I'm talking about, I'll get you up to speed.  When ideas are connected, I want to allow the user to attach some data to each connection.  For example, when a scene is connected to multiple characters, the user might want to attach a small caption to each connection to explain the role of each character in the scene.

And so that you understand what I'm about to discuss, I'm going to explain a bit of the internal structure.  If you don't know anything about relational databases, you may as well skip this post.  Anyway, each idea type is a table in the database.  When the idea type allows only one connection, there is a column in the database that links to the other idea type.  However, when an idea type allows multiple connections, there is a separate table, each record representing a connection.

It's obvious how to do it when a field allows more than one connection.  In that case, I could just add the fields to the separate table.  However, when only one connection is allowed, I could possibly add the link data columns to the idea type's table as well, but that could get messy.

My initial thinking was that if they only allowed one connection, they wouldn't need separate data for that connection.  If they wanted data attached to it, they could just add more fields to the idea type.  After all, the link data is there only to distinguish the connections from each other.  When there's only one connection, there's no need to distinguish anything.

However, say the user initially allowed multiple connections, but wanted to switch it to only allow one.  What would I do with the existing link data?  Throw it out?  Merge the fields into the idea type itself?  Hmm...that's actually a decent idea.  Anyway, see what I mean?  It's a dilemma.

Real quick, I want to continue the thought from the previous paragraph about merging the link data fields into the idea type.  On the flipside, if the user wanted to change the column from allowing only one connection to allowing multiple, I could allow them to choose certain columns from the idea type to merge into the connection data.  I think I like it.

However, I'm going to mull this over in my brain for a bit before I make any brash decisions.  I'm going on vacation for the next week or so.  I'll have plenty of time to think about it while I'm gone.  Hopefully by the time I get back, I'll have something solid in mind.

I hope this blog is at least somewhat interesting.  Once I get past this internal stuff and move on to the UI, it should get a bit more exciting.  I really can't wait until then.  If you have any comments or suggestions, please send them my way.

Thanks for reading!
clevceo