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

Testing

I was starting to get a bit scrambled with all the code I was writing, and I knew that there were probably a thousand bugs in the code that I had already written, so I decided to take a break and test what I had written so far.  I made a simple interface, and started diving into the bugs.  I'm very glad I decided to do this early on because I found even more differences between SQLite and MySQL, which required some rewriting.

I am only testing the general idea types at the moment.  I haven't tested the actual idea instances yet.  In fact, I haven't even started testing the idea types' columns yet.  I'm just touching the surface.  There's a surprising amount of testing to be done on every level.  However, I'm almost ready to start testing the columns.  I only have one more thing to test, and it has to do with inheritance.  Alot of work went into the code behind switching an idea type's inherited type.

There are three different scenarios I have to account for.  First, when the new inherited type is completely unrelated to the former inherited type.  Second, when the old and new inherited types share a common ancestor (I have to make sure all data that the two share is preserved).  Third, when the new inherited type is the type's descendant (which basically means that the type will inherit itself).  The first two are done for now, but the third has yet to be tested.  Originally, I wasn't going to allow the user to do the third one because it sounded like a mistake.  However, I found a way to make it work.

If you think of inheritance like a hierarchy, I'll remove the type from its old spot and fill the gap by tying its descendants to its ancestors.  After that, I'll stick it in its new spot.  That way, there won't be any circular inheritance.  This was a bit tricky to implement.  My brain was a bit fried for a few days, so it took me a while to pin down the best method, but it's written.  All I need to do now is test it.

I'm excited to finish testing this last step because that means I can move on to the columns.  Once they're mostly done, I'll likely move on to writing the link data that I mentioned in my last post.  It's a bit daunting, but I can't wait until it's done and working.  I've put alot of hours into this iteration of Idea and I'm ready for the gears to start turning.

In case you're curious, this is what my little test form looks like so far:

No, this is most definitely not what Idea will look like in the end!  This is strictly for testing.  Idea is only a library of code right now, and this form lets me play with the library.  After I feel that the library is complete enough, I'll start coding the real interface...hopefully.  I still have to figure out the best way to do it.  That's where I'm still a bit stumped.  Heck, I might go through multiple iterations of it before it's done, and that's fine.  It will be alot easier with the foundation already completed.

Thanks for reading!
clevceo

Link Data

I've been thinking about something lately.  It's about the links between ideas.  For example, linking a character to a scene.  What if you wanted to attach a caption to that link?  For example, you could say what role the character plays in the scene.  Of course, you could put this in the scene or character ideas themselves, but the scene has alot of characters, and each character is in alot of scenes, so it could get messy.  If I could attach that caption to the link itself, then that would resolve the issue.  When expanding the link to look at the character, it could show the caption as well.  I'm not sure how I would display that in the UI, but it could be extremely useful.

As I thought this through, I thought "What if they wanted to attach some other kind of data to it, like a number or a picture?"  I realized that I can't restrict it to a simple caption.  I have to allow the user to decide what data to attach to each link, if any.  Each link will be a miniature idea, containing a list of fields.  However, this introduces some new complexity.  I might have to set some boundaries for it.  For example, the link ideas can't inherit.  And "maybe" they can't link to other ideas (since it's already a link anyway).  The rules are likely to evolve over time.  Hopefully this doesn't get too out of hand.  I don't want to bite off more than I can chew.

This makes Idea a bit more daunting, but I think it will be a really nice feature.  It will help keep things organized.  Anyway, thanks for reading!

clevceo

User Interface

I'm still working on the inheritance code.  It's alot of work and my free time is sparse.  However, in between coding sessions, I've been thinking about what I will build on top of the base Idea library.  Basically, all I'm working on now is the base file storage for the base idea structure.  So far, I haven't even touched the UI.  Thinking about it is a bit stressful.  Since there are no precedents, I'm not exactly sure how to do it.  However, I have a few ideas.

There are two specific ways I want the user to be able to interact with ideas so far.  First, they will have a basic drawing board.  They can drag and drop ideas onto it, arrange them how they please and edit them while they're sitting there on the drawing board.  This is the most basic UI idea I have.  In the finished product, this feature might evolve drastically or even be tossed, but I think it's a good starting point.

Second, I want the user to be able to create his/her own interface for the ideas.  This will be similar to Microsoft Access forms.  I think this can be very handy if done right.  Then again, I haven't tried it out, so it might backfire.  But all ideas are good ideas until proven bad, so I'll give it a shot.

The drawing board will be my first project, just so I have a playground to test things out.  It will likely change alot over time.  My ideas for the UI aren't nearly as solid as the idea structure.  At the base level, a saved drawing board will store which ideas are in it and their locations.

However, there are a ton of other features I've thought of as well.  Here are a few random ones:

• Hiding certain fields in an idea.
• Hovering over a minimized list field will show a small sub-menu that allows them to either expand the list within the idea or show the linked ideas to the side with lines connecting them.  Maybe rather than a typical menu, the choices would be visual.  In other words, to the side would be a faint image of lines branching out to squares and below it would be a faint image of a list of idea names.  They need only hover over one and click.
• Operations on multiple ideas at once.  For example, if the user selects a group of "scene" ideas, then he can have them all show the "character" ideas linked to them.
• Automated arranging.  Somehow, I'd like to allow the user to make the layout of the drawing board automated.  In other words, when the user expands a list of ideas next to a parent idea, rather than just placing them on top of other ideas, arrange them in a visually pleasing way...somehow.  I'll have to research that.  The biggest difficulty would be dealing with all the "link" lines running around.  Maybe I'd have them go "around" other ideas rather than keep them as straight lines.  We'll see.
• Masks.  A user can create a "mask" which is a preset view for an idea type.  In the mask, the user will set how the idea will be displayed on the drawing board.  For example, he/she can choose which fields will be displayed, which ones are read-only, etc.  The user can set certain drawing boards to only show certain ideas with their masks or the user can open individual ideas with certain masks.

That's just a few.  I need to keep track of them all.  I'm excited about it, but it's definitely daunting.  While I hope to be done iterating the foundation of the software, it's time to move on to the UI.  I've made so many iterations of the foundation, but every iteration of the UI (there have only been a couple that were usable) has so far only been basic.  I only made them so I could test the software.  This time, I'll make additions to the foundation and evolve it slowly, but I will not start over on it.  SQLite makes it easy to keep the changes small.  But the UI will go through huge changes over time.

I really want to keep it fairly experimental for a while.  Idea is a new animal.  No one has done it before.  I have no precedent, so I don't want to try to make it work like existing software that I've already used.  I'll borrow ideas, of course, but I'll also make up my own.

If you can tell, I'm excited about Idea.  I want to get past the foundation so I can start playing with UI.  It will be a little longer before I can, but I'll keep trucking along.  If you like my ideas or if you have one of your own, please let me know.

Thanks for reading,

clevceo

Inheritance

Lately, I've been implementing all the database interaction.  Using a database is really an ideal way for Idea to work.  However, there are a few things that databases don't necessarily do well that are important to Idea.  The most prominent is inheritance, which I talked about in my last post.

Inheritance is an important concept in object-oriented programming, but it's non-existent in relational databases.  Therefore, I had to come up with a way to imitate it in a database.  I can tell you, it wasn't easy.

Sometimes things just click and I gain momentum, and I never seem to hit any ruts.  Well, I was that way in my first few iterations of Idea, but I'm not that way now.  It's mostly because my current version requires alot of work on the foundation before I can ever even test the thing. So far, I've had to hold everything in my head, and I'm doing something that hasn't really been done before, so I don't really have any precedents.  The best way to do things isn't very obvious.

Before, I just jury-rigged everything, but now I'm focused on quality and performance.  This time, it's not just a fun experiment.  This time, I really want to take it somewhere.

Thus, I was determined to find the best way to implement inheritance.  I'll be honest, the first way I thought up seemed really nice at first, but then I realized that it opened a huge can of worms when changing existing idea types' settings.  Then I came up with my current method, which at times seems a little tedious, but it utilizes the nifty perks of relational databases better, which actually make things sooo much easier in the end.  For example, if you were to change an existing idea type's inherited type, the old way would have been ridiculously hard and impractical.  The new way, while still difficult, makes it infinitely easier.

I'm actually a bit proud of my inheritance code.  However, it's probably riddled with bugs.  I haven't tested anything yet.  I'm excited to get to that point.  However, I know I'll spend a couple days just ironing out bugs.  But that's fine with me.

Thanks for reading!

clevceo

Idea

This blog has been sitting here on the internet for years, so I assumed that somewhere down the line, I must have explained what Idea was all about.  However, today I looked back and the first post has a link to an explanation, but the link is broken.  I have no idea where it linked to.  Fortunately, Idea has evolved since then, so it would have been outdated anyway.  I figured now would be a good time to tell what Idea is and means in its current form.

Idea is an idea organization tool.  I know that's vague, but there's no other way to say it.  I think a good way to explain it would be to tell how I came up with the idea.

Years ago, I was interested in creative writing.  I bought a few books by big authors about their writing process and I swallowed them whole.  Steven King says he usually plans out a good beginning situation and then starts writing, never knowing what's going to happen until he writes it.  Terry Brooks, on the other hand, outlines everything before he puts a word on the paper.  I figured I'd probably lean towards Brooks' method, since I'm not that good at improv.

Terry Brooks explained his method of outlining.  Most of us picture an outline as a numbered list, like we all learned in school.  However, his outlines consist of post-it notes, note cards, etc. scattered on his wall or desk.  He puts one idea on each note card or post-it note so that he can order them, group them, and rearrange them as he pleases as he plans out his story.  My mom likes post-it notes, but they would put my mind for a spin.  I'd be in a constant jumble with notes surrounding me.  I'd lose notes, I'd forget where I put them, I'd, I'd, I'd...  Long story short, I'd go crazy.

I began to wonder how writers managed to write an entire novel and keep track of everything.  Being a computer-person, I began to wish there was some sort of software that could keep track of it for me.  Soon, I had a fairly solid idea how that software could work.  All of a sudden, I realized that as a programmer, I would be able to develop that software myself.

Unfortunately, I was a very new programmer at the time.  I didn't have much experience.  However, the experience I gained while working through each iteration of Idea got me my current job, and my current job gave me the skills I needed to complete Idea.  It also helped me to solidify the design of Idea.

While I don't yet know what all bells and whistles I'll add to the software, I know its under-workings, which is honestly the most uniquely important part of the software.  If you're a programmer, you'll probably recognize some of the principles as I explain the philosophy behind it.

The bare bones of it is that I wanted to imitate the post-it note method on a computer.  What's different between a post-it note and a written document or even a specialized note program like OneNote is that a post-it note is an individual entity, separate from all other ideas.  In a document, each idea is merely a block of text mixed with all of the other ideas on the same page.

Say for example, you have a post-it note for each character.  You can put the characters relevant to a certain scene next to you on the desk as you plan it out.  And if you want to add a character, grab the other character's post-it note and put it next to the others.  Also, you might have a post-it note for each setting/location.  You can just grab the right one and put it in the group.  Each note is a building block.  Whereas in a document, you have to write it all out, meanwhile flipping back to the characters page (if you remember where it is) to make sure you're staying consistent.

Idea allows you to create standalone ideas and mix and match them as you please.  It seeks to streamline the idea generation and development process.  However, it is not only for writing.  It is designed to be used for just about anything.

To see how it works, you must first understand what an idea consists of in this software.  An idea is a list of fields that contain data.  For example a "character" idea might have the fields "First Name", "Last Name", "Age", "Occupation", etc.  A "setting" idea might contain the fields "Name", "Country", "Description", etc.  Then you'd have a scene idea with the fields "Name", "Characters", "Setting", and "Plot Summary".  Now here's the cool part.  "Characters" and "Setting" are fields that contain other ideas, and "Characters" is actually a list.  This is where you match the ideas together.

You might even have an idea type called a "time line".  The "time line" idea would contain an ordered list of scenes.  Imagine seeing the list of scenes on the screen.  You can drag them around and rearrange them as you please.  You can also tell it to show you which characters are in each scene, mixing and matching as you go.  You can get a birds eye view of your story, only seeing the surface details, or you can dive into a scene, shutting everything else out and showing all the nitty gritty details.

You are the master of the idea types.  Until you're more comfortable, you can stick to prefab types.  However, when you're ready, you can edit the prefabs or create your own idea types, allowing you to use Idea for just about anything.

Now here comes a more complex concept.  What if you were writing a fantasy story and you'd like each class of character to have its own fields?  It would be a mess to just add all of the fields in and only fill the relevant ones, wouldn't it?

The answer is a programming concept called inheritance.  One idea can inherit the properties of another.  I know that sounds confusing, but hear me out.  Say you made a base idea type called "character" with the general fields "Name", "Gender", and "Short Description".  These fields would apply to any character.  Now, say we made another idea type called "wizard" with the fields "Powers", "Wizard Type",  and "Wand Wood Type".  Then we made another called "elf" with its own fields, and another called "human" with its own fields.  Then, we'd have all of them inherit "character".  That means they'd all share the fields contained in the "character" idea type, but keep their own unique fields.  A good way to look at it is this: wizards, elves, and humans are all kinds of characters.

Now, remember that the "scene" idea type asks for "character" ideas, not "wizard", "elf", or "human" ideas.  That means that as long as the idea is a "character" or inherits the "character" type, it can be added to the scene.

That completes the basics of how Idea works.  It's only a few principles, and I might add more later, but I think it can go really far.  I want to the interface to really make the process feel simple and intuitive.  There will probably be alot of prefab idea types to begin with if you'd like.  Creating the idea types themselves might be the unintuitive part, but people can figure it out and take the software alot farther as they learn.

So there you go.  An explanation of Idea.  I hope it wasn't too confusing.  Let me know if you find it interesting, you have questions, or anything else.

Thanks,

clevceo

SQLite

Well, here I am working on Idea again.  It's been a long time, and I don't think it will be finished any time soon, but I at least want to get a simple version on its feet so I can play with it.  In my last post, I mentioned that I didn't know what database software to use, but that's behind me.  I'm using SQLite.  When I read up on it, I realized that it was exactly what I'd been looking for.

I'm working on the foundation of the software at the moment.  I have a decent idea how I want it to work, and it's coming along nicely.  I've got the database pretty much designed, and now I'm implementing it.  The problem is that SQLite's version of SQL leaves out some handy features.  For example, you can't drop or modify columns once they're in place.  Instead, the way to do that is to copy the data into a temporary table, drop the table, recreate it with the changes, and copy the data back in.  It sounds like it would make more sense to just create one new table, copy the data over, drop the original and rename the new one, but that would actually mess things up.  In other words, it's a bit inconvenient.  However, I'm going to make it work, and I'm excited.

SQLite is the absolute perfect solution to the issues I had with Idea's design.  It's no longer impractical and really hard to manage.  I could go on and on why this solves all of my life's problems, but I won't.  Just know that this makes my life soooooo much easier.  Basically, once I have this part developed (which will be soon), then I can start experimenting and having fun.

Anyway, gotta go.  I hope to keep this updated as I continue to build it.  Thanks for reading!

clevceo