My Internet Software Experience

I’ve known since my Capstone project that I don’t want to do web development if I can help it. ASP.NET has it’s perks (User Controls, a strict page processing life cycle, Databinding, automated scripting, and automatic state handling), but it obfuscates some of the processes and forces you down some weird roads. Ultimately the real problem was that ASP.NET’s best features are ones that cover up the deficiencies and annoyances of standard web technologies.

The HTML/Javascript/CSS trifecta continues to be vexing. Whether hidden by ASP.NET, managed by frameworks like jQuery and Bootstrap, or manually composed, these three tools still act like desktop publishing tools instead of UI building tools. I hate designing applications around the quirks of the UI tools.

PHP is also frustrating, but for different reasons. Having become so accustom with type safe languages, working with weakly typed languages feels like punishment, especially when types matter between different layers (the database expects specific types, while php and Javascript act like they don’t care about types, but subsequently complain about a type mismatch). The messages moving between these layers get packed and unpacked so many times that I imagine they must look like balls of duct tape and cardboard by the time they arrive at they’re destinations.

The biggest challenge server side was working with mysql. I’m sure if I spent more time working with mysql console commands then I’d be happy with it, but it was constantly in a state I couldn’t visualize and it was particularly unfriendly when I asked for help.

As much as I hate these technologies, I do understand that almost all of the CS jobs for my level of education and experience are ones making chintzy CRUD applications for the web. When I tell people my field is computer science, most people want to help me find jobs fixing hardware and setting up networks. After all, I am the person they come to when they need their router set up or if they need someone to hold their hand while I tell them they have to connect their monitor to their computer for them to see what’s going on, so obviously this is what I’m talking about when I say I work with computers. Given web development isn’t quite a menial as that, I thought I might come out of this class with slightly more appreciation for what will inevitably be the next 4 years of my life writing the boiler plate and never quite what you want markup for a UI. This was not the case.

This is already my second pass at a ‘career minded field’ and I don’t feel like doing a third pass now just because I think I’d be happier in Electrical Engineering. When people talk about needing highly skilled workers in the IT field, I don’t feel like they’re talking about what I’m almost certain I’ll be doing: making glorified electronic paperwork. So my opinion of web applications hasn’t really changed. The tools are crumby and every application is essentially solving the same problem: how do I present and store my data?

I did learn things though, and not just on the language front. I didn’t understand web services before this class, despite furiously reading through everything I could find on the subject. The design of my application touches on the web service though, even if it comes up short in a few areas. The only thing I’m getting back from php is usually a 1 or a 0 to let me know if the server side code worked or not, or an appropriate JSON encoded object. My misguided failures at poking the twitter API are framed with more context since I’ve had the opportunity to explore what it’s like to pass http requests to a server in order to get data for my own applications. I don’t know if web services are the future, or if Azure will really take off and cascade into the development of several cloud based RDBMSs, but the client-server relationship and http are two things I have a much better understanding of now.

In summary, I confirmed my suspicions about how convoluted and arbitrary the HTML/Javascript/CSS relationship is, I learned a little bit about web services, and I got to poke at an unfamiliar database. That said, I sorely missed having an individual on my team responsible for my database. When I graduate this semester and look back on my education over the last two and half years for what skills I learned that will be most marketable, my guess is that I’ll be pointing at what I did with Breadknot more than what I did in most classes. Even if I’d rather be doing more machine oriented programming, at least I now have well informed disdain for web tools.

Posted in CSIT2230 | Comments Off on My Internet Software Experience

Security: The World Wild West

I’ve never given much thought to security, perhaps it’s my naturally cautious habits that prevent me from worrying too much over what I’m sharing over a network. I understand the exploits and vulnerabilities, but choosing not to participate in the information sharing is an even scarier thought.

I’m intrigued by the technical challenges involved, but disinterested in exploring other people’s information. I have no desire to be a master of hacking techniques because the places it goes aren’t all that interesting. As much fun as it is to dig into a system, I just don’t care enough about what I’ll find there.

The real pain is that enough intelligent people have little enough to do that when building a system I have to consider how they might choose to break it. Security is a pain. Ultimately what it amounts to is the difference between burning paper and burning wood. One of them will take longer, but if the flame is persistent then you’ll always end up with a pile of ash in the end.

When building my system, I was aware of all the vulnerabilities associated with Javascript powered logic and ajax data transfers. I’m aware of them because of how easily I can see ways to cheat my own system, which is why it surprises me somewhat that this easily breached model is so popular. Has no one looked at alternatives?

Progress: I’m poking the quest edit/add feature into place. Problems keep cascading out of the minute adjustments I make. It’s “working” in so much as I’ve seen it perform the updates and return the appropriate changes. My concern is that it’s extremely fragile. There are some countermeasures in place, however, it tends to fall apart if one of over a dozen pieces is ever so slightly out of place. A pity, but not unexpected.

I hope to clear up the issues over the week and implement the claim and approval system for the quests. Unfortunately the rewards system is out of the question at the moment, at least in terms of how I’d like to implement it, however, that’s what holiday breaks are for.

Posted in CSIT2230 | Comments Off on Security: The World Wild West

Mobile: As Appropriately Lazy as Expected

I’m getting into Mobile development because the Windows Phone market is pretty bare, and I’d like to see if I can’t fill in some of the gaps. Some of the apps are there, they’re just shoddily produced. Most notably, I can tell when I’m being presented with a webpage vs an application designed for the OS. The former is almost always more difficult to use, understand, and predict.

The economics of this aren’t foreign to me. It’s far easier to hire one good web developer to design cross platform web applications than it is to hire someone or multiple developers who are proficient in Objective-C, C#/VB, Java, and all the web technologies. The investment in time is considerably lower as well.  I get that. It’s just a shame to me that the cross platform tools of choice are a poorly standardized markup language and a weakly typed programming language that both pretends to be object oriented and leans heavily on an unstandardized library. This is ignoring the fact that PHP appears to be the preferred server side language of choice, and it’s riddled with inconsistency as well.

Mostly what I’m saying is that the tools for this lazy cross platform development option are not ideal. There is an elegant quality to the idea of having one set of tools to rule them all, but it’d be nice if those tools didn’t have so many “It’s not ideal, but it’s just the way things are” types of issues.

SOAP models of data distribution and the API’s that are being created to allow access to data are a great start to solving what is ultimately the most aggravating issue in these CRUD applications: statelessness. If all I’m using the server for is data modeling and data logic, then I see no reason not to let the server just be a distribution entity. Let me design the UI and State logic however I want, but just pass me the appropriate data for the read and display parts and let me pass you the relevant parameters for the create, update, and delete part. This conversation belongs in the URL and HTTP headers and everything else belongs to the client.

I digress. If I turn this mobile, it’s going to be using tools that I’m more familiar with and that are easier to modify and monitor. Maybe their’s some secret to the web tools we were handed this semester that is an ideal method for application development, but a good design is hard to come by when there’s no telling what PHP will give back and when the presentation and it’s controlling language are so disjoint.

As for status, I have the read working. Quest data can be displayed at all levels, and there is a default for null returns from the database. I wrote the update and insert functions a couple of weeks back, now I just have to successfully tie it to Javascript functions. The difficulty is the change of datatype among the languages. I switched to timestamps for the date because it was the most frequent default among the the languages. It’s coming along nicely though.

Posted in CSIT2230 | Comments Off on Mobile: As Appropriately Lazy as Expected

jQuery: A Matter of Convenience

Link to Site:

Link to jQuery Sample:

jQuery Quiz: 20/20

I wasted too much time on the jQuery sample. What seemed like a simplification was more of a complication. No animation is worth the amount of trouble I went through with the slide animation (I still didn’t get what I asked for despite trying numerous recommendations). No user input, just data from the database. After 5 hours of kicking the slide functions around, none of the tricks were working and I gave up getting both slides.

I’m a little more than aggravated by this distraction, mostly because I’ll never have the time to put this knowledge to good use in my project, but also because it compounds the time lost as a result of two other constant issues that keep popping up. First, there is major inconsistency with the database issue. Locally I can do just fine, but the ps11 database constantly appears to lie about what is and isn’t in it. I have to perform an export of my local database to get it working and the success of that script is wildly up in the air, consequently my application sometimes magically works or doesn’t depending on how mySql feels about the last script. Second, PHP is a nightmare to work with given the tools I have. I’ve only recently gotten the PHP to behave with the database. I don’t see how it’s fair to have a loosely typed language kvetch about an expected datatype in its parameters, especially when the parameter is a result returned from a function meant to return that parameter. That’s just stupid.

All problems aside, I’ll first admit that I’m behind. I wanted to have user and quest data represented by an return from an AJAX query. At this rate I’ll be lucky to have the “add and edit user” administrative tools working by exam time. Still, now that I’ve overcome some of the more daunting hurdles, it should be more typing than coding. The below is unchanged from the previous week.

  1. Revise site per demonstrated design flaws. (Complete)
  2. Create Admin Dashboard (Complete)
  3. Create Javascript functions for state swap of presentation layer (Complete)
  4. Have Database Created (In Progress)
  5. Establish PHP Login for manually inserted user (Complete)
  6. Operable procedure for adding user to database from Admin dash using PHP (In Progress)

Users need only press the login button gain access to the site as Admin. The only changes have been cosmetic and the addition of limited Admin functionality.

Posted in CSIT2230 | Comments Off on jQuery: A Matter of Convenience

HTML5: Not an Option

Link to site:

HTML 5 Quiz: 20/20

I remember someone describing HTML 5 to me and thinking to myself “That really pigeon holes people into a predefined space, even worse so than HTML already does.” After finally going through it and learning what it’s made of, I was sort of astonished at how easy some of it’s elements would have made my life. When I looked back at my project though; pigeon holed. I’m not happy about it.

I’ve built my database for users and quest items. I’ll add the rewards when I’ve decided how to execute them. I wanted to repeated quests and to do that I’d have to have a list of completions. To implement this, I’ll probably bridge the quest table and the rewards table to represent completions, thus preventing a multitude of repeated data by templating the quest and reward once. Again, I’m not sure about this yet, and would just like to nail down the process of passing data between the server and the client before expanding on the data being delivered. I’ve also got tables for quest and reward categories too, but they’re not as robust.

What did I accomplish this week? Finally managed to nail down the procedure for handling state and finally got around to introducing the login. Now I need to move my test data to the database so I can see it come in over the AJAX line. I’m going to collect all the data at login and pull up bits and pieces where necessary. I have an object composition down, I just need to translate the process between server and client with JSON. I might even put an update timer or a sync button in. Alas, I’m not there yet so I need to spend a little time with it.

To be fair, I spent the better part of the day hunting down a mysterious problem wherein PHP was returning an empty record set from my user table, while MySQL was adamant that there was a record in the table. I learned a lot about PHP that day, but am still upset that I was chasing an uncommitted record all day.

Installing Apache/MySQL/PHP: I’ve been working out of Aptana since day one. I was hoping that I could use the SQL Explorer plugin to directly connect to PS11, but that proved fruitless (another wasted afternoon). I installed XAMPP as soon as we started PHP, and it has been fruitful, it just means that I’m doing everything locally. I’ll export the database when I update the production instance, it’s the only option. I even tried to get Aptana to do PHP debugging, but I seem to have misunderstood the way it works and can’t get it to stop at breakpoints (again, whole evening down the drain). A lot of time has been lost on new technologies, which is why I don’t like introducing more than one or two in a new project. PHP and MySQL, sure, but the cavalcade of constant interruptions in the form of Bootstrap, IDE, and server trouble has been a costly.

Which brings me to a point about Git: Not this time. I’m no stranger to tackling a lot all at once, but I’ve got a good rhythm going and I don’t want Git getting in the way, not to mention what it would cost in time to set it up and learn to use it. This isn’t to say it’s not a valuable tool though. I’ve suffered issues in version control and would like to have a better system than “The one you work on is test, the one that’s visible is production.” Tracking versions by checking out entire versions at a time instead of just individual files is ambitious too. I’m sold on the concept and it’s benefits, just not on the timing.

In the mean time, I’ll get the Add User feature running, then plug in the data pull stuff, gonna be cool.

  1. Revise site per demonstrated design flaws. (Complete)
  2. Create Admin Dashboard (Complete)
  3. Create Javascript functions for state swap of presentation layer (Complete)
  4. Have Database Created (In Progress)
  5. Establish PHP Login for manually inserted user (Complete)
  6. Operable procedure for adding user to database from Admin dash using PHP (In Progress)
Posted in CSIT2230 | Comments Off on HTML5: Not an Option

MySQL: The Bottom Layer of the Cake

Link to Site:

I’ve been playing around with PHP, just to see what I can make it do. I haven’t honestly fiddled too much with the MySQL since the majority of my time has been spent trying to spruce up the look of the site and setting up and appropriate testing environment for the PHP and MySQL. This means that I haven’t tried out any database connectivity with PHP and MySQL, but I’m well read on the subject, and will have an AJAX driven login by the end of next week.

In the mean time, the question at hand is what does the database look like? Well, I only need to represent two objects (initially), the user and the quest/task. Users have a reflexive relationship, where managers are users and so are their subordinates. As long as that’s a one to many relationship, then I can keep them in a single table having a self referential key for users called ManagedBy. The rest is just data: name fields, password, privileges, etc.

Quests are reflexive too. There’s necessarily a one to many relationship between quests and their subquests, so a self referential key called SubOf will maintain that relationship. The AssignedTo and IssuedBy fields are Foreign Keys of users, and most of the data is descriptive text: description, name, notes. IDs will be automatically generated. DueDate is pretty straight forward, but Completion is the tough one. I’d like it to be calculated for non-subquests (i.e. Primary quests will have a Completion derived by taking the average Completion among it’s subquests). Then there’s the Category…

The Category will reference a descriptive table for QuestCategories. This is because I ran into a problem this week with my last application where a request was put in to have a category added, and the design forces changes in about a dozen places. If the data flow is written well, then I should be able to add a category to the table and have that reflected all the way back up to the presentation layer.

The same should be true of Reward Categories. The implementation of rewards is on hold until I get other things figured out. In the meantime I have a table arranged for tying rewards values to their respective quests and the user the reward is assigned to.

In terms of whats being accomplished, well,  the HTML/Javascript union is a bear. The single page design means that the site has to be constantly aware of the state, and I’m having trouble keeping the UI together especially since I’m not sure how data is going to flow into the client side. It just means I’m going to have to pull double time to get the data layer in operation over the course of the next couple of weeks. That said, I’m not too enthusiastic about HTML5 and CSS3 being required elements.

  1. Revise site per demonstrated design flaws. (Complete)
  2. Create Admin Dashboard (In Progress)
  3. Create Javascript functions for state swap of presentation layer (In Progress
  4. Have Database Created (In Progress)
Posted in CSIT2230 | Comments Off on MySQL: The Bottom Layer of the Cake

Exam 1: Workshopping

Site Link:

Quiz: 20/20

This reminds me of having stories workshopped; what’s working, what’s not, what is or isn’t contributing to the story, etc. Not exactly the same, but having my work reviewed is at least familiar territory. I know I don’t take criticism well, even positive. Here, I’m trying to be as honest with myself about the effectiveness of my design while using the criticism as a spring board for exploring problem areas. I’m too close to it to have an end user experience.

So, what was revealed by the review process…

  1. No one mentioned quest/task types, this needs to be more strongly exposed
  2. The empty value on login confused people, a reminder that there need to be default values for empty or null.
  3. There was some confusion about how tiers 1 and 2 affected each other. I can live with pushing tier 1 out to the menu to ‘separate’ the tiers a bit. In fact the top menu has always looked sparse and would benefit from a clear separation of tiers, including tier 0 for views (separating it from login).
  4. The activity in charms is evidently a bit misguided. I was sold on the concept before, but it’s evidently not an obvious approach. As long as I’m separating tiers into top menus, I’ll push the actions out to them as well. I’ll leave the charms for tier 3.
  5. People seemed to understand the concept, but it was misunderstood as Project Management rather than Task Management. I need to make the purpose more clear from the splash page. I’m looking at Trello to see how they sell their concept.
  6. Apart from simply being confused about the way the tiers are set up, users weren’t clear on how to use the system. I’ll build an initial quest that will tutorialize the use of the system for new users to make it more clear. Users are also more likely to engage if they’re “Gifted progress” than if they have to start from scratch.
  7. There was some dissatisfaction regarding the features. It was called boring and unengaging. The above is one method of engagement, but I can do more. If time permits, I’ll implement a bounty quest type which will be quests that can be claimed by anyone. I’d also like to create a system of milestones based on rewards, though this is a phase II feature to me if only because it’s a largely attached to customization. Basically, it’s been noted that it could be expanded and that some ideas are in the works, but I’m going to focus on core, which requires time of use to be effective (with managers forcing the issue, users will be engaging with the system anyway).

So, screens…I can’t really link to screens, but bear with me. I’ll get the point across.

  1. Welcome Panel: This panel is meant to convey the purpose of the site and invite the user to use it. This welcome screen includes the login process and is only visible prior to login.
  2. Main Panel: This panel is visible after login and represents the quest, quest content, and rewards info for a selected user. The user is selected in the view menu, with the initial view being the logged in user. The content is sensitive to the view context, i.e. actions available for the users data are different from actions available while viewing subordinates’ data. New quests and sub quests can be assigned (by altering the content screen so that content is replaced with empty form fields). Editing quests works the same way. This is also the Panel from which quests are claimed and quest completion is confirmed. Essential if it’s a quest related operation, it’s done here.
  3. Admin Panel: This panel is a Dashboard selected from View in the Main panel and is an option only visible to Admin privileged users. This panel is used for adding and editing users. New users are added with a manager (only users with admin privilege are allowed to be added without a manager). Subordinates can also be added/changed, but only for an existing user.

So now let’s talk about my next steps

  1. Revise site per demonstrated design flaws.
  2. Create Admin Dashboard
  3. Create Javascript functions for state swap of presentation layer (i.e. show the right things in the right view).
  4. Have Database Created (not necessarily apparent)
  5. Establish PHP Login for manually inserted user
  6. Operable procedure for adding user to database from Admin dash using PHP
  7. Operable procedure for assigning quests
  8. Display quests assigned to logged in user
  9. Display quests assigned to employees of logged in user
  10. Operable procedure for editing quest notes
  11. Operable procedure for editing Users
  12. Operable procedure for editing Quests
  13. Operable procedure for deleting Quests

That should be good for this stage, the next stage will be focused on rewards and quest completion.

Posted in CSIT2230 | Comments Off on Exam 1: Workshopping

Javascript/DOM: From Paper to Screen

Link to site:

I’m pretty determined to make my site AJAX driven when the time comes. This week I outlined a series of Javascript methods for updating and altering the page depending on selections made and the data objects defined. (This is to preserve the site as a single page with AJAX updates). It’s based on cascading updates from the login up to the content. I’ve defined it in four tiers.

Login->Tier 0: View->Tier 1: Task/Quest->Tier 2: Sub Task/Quest->Tier 3: Content

The meat of BreadKnot is in the quests: what I’m building is a task list at its core. That much I have working. The next big challenge is what makes BreadKnot unique, the rewards. In the big picture, the reward types would be determined by the organization using the application, but for now, but in terms of scope that’s a bit ambitious, especially since the technologies being used to implement the solution are new to me (PHP, mysql, and AJAX are all unfamiliar territory). During the course of the semester, I will finish Phase I, but if time permits I’ll push in Phase II.

Phase I Requirements

  1. Quest/Task list built on Main, Side, and Repeated Tasks
  2. Quests/Tasks support subtasks
  3. Quests/Tasks are valued with a set of points awarded in different categories
  4. Users have full CRUD permission for Tasks and Subtasks of subordinates
  5. Users may approve completion of subordinates’ Tasks and Subtasks, awarding points
  6. Users may claim completion of tasks assigned to them
  7. Users may see rewards they’ve earned

Phase II Requirements

  1. Organization may define rewards available for Task completion
  2. Subtasks may have subtasks
  3. Organization may define new types of tasks
  4. Users may document progress on tasks
  5. Organization may define categories of users based on users’ earned rewards

At the moment, I’m faking everything with Javascript, hopefully those functions and objects will transfer well when it comes to implementing the AJAX methodology. This is just for the task list and user concept though, so I’m faking rewards presentation with straight HTML. The product is operating close to what I expect the final product to, but I’m guessing I’m going to get some good design input on user friendliness.

Completed Work

  1. Second pass at design layout with Bootstrap in mind (HTML and CSS)
  2. Bootstrap customization for metro look and appropriate colors (LESS CSS compliation)
  3. Recreate new design using Bootstrap (HTML and CSS)
  4. Created drop-downs from Bootstrap framework (CSS, Javascript, jQuery)
  5. Created Cascading Update functions (Javascript)
  6. Designed Javascript objects for Users, Quests, and Rewards (Javascript)
  7. Faked data with literal Javascript objects (Javascript)
  8. Developed Color coding for Quests (CSS)
  9. Added rewards to the Navbar (HTML, CSS, Javascript)
  10. Faked rewards page (HTML and CSS)

Discarded Work

  1. Created Header and Login(HTML, CSS)
  2. Created Views Menu and Menu Items (HTML, CSS)
  3. Created Quests Menu and Menu Items (HTML, CSS)
  4. Created Mock-Up Charms Bar(HTML, CSS)
  5. Created Definite layout (HTML, CSS)
  6. Created Two Color Scheme with Accent (HTML, CSS)
  7. Created Common Styles (CSS)
Posted in CSIT2230 | Comments Off on Javascript/DOM: From Paper to Screen

Javascript: A Shot of Caffeine

Javascript Quiz


Link to site:     <–Bootstrap Alteration     <–Previous Vision

This week has been less about Javascript for me than it’s been about wrestling with Bootstrap. The framework is difficult to customize and doesn’t feel like it was built to handle applications, at least not the way I think of them. Still, I was able to tease the color scheme and a new design for the site around the Bootstrap content types. However, it has forced me to consider a UI that is a little simpler, which is what I was shooting for…boundaries expose new freedoms I suppose.

That said, I’m working off the framework’s Javascript files, as well as their use of the jQuery plugin, which is a lot of copy and paste, but it’s attractive and effective, so I don’t see myself letting go of it for the sake of learning. I’m still learning the framework (which is a bear) and there will be plenty of opportunities to work Javascript and jQuery into the forms that I’m not too worried about missing out on chances to see it at work. At this point, I’m taking to heart a comment made by a colleague about an interview in which he explained that he wasn’t as impressed by the candidate who did everything by hand as he was by the candidate who was “effectively lazy in his use of framework’s and IDEs.” The point being that I’ve done enough Javascript to have a handle on the concepts and it’s more valuable to me to know how to use the frameworks and plugins designed by experts.

A request was made for pictures and prototypes of my screens, but if I’ve designed this right then there are only two different screens, built on basically the same layout: a welcome/login screen and a content viewing screen. The trick is changing the context of the content based on the user’s relationship to it. A manager may change his employee’s quests and approve completed work, but won’t be able to alter quests of his own.

The previous layout was described by those I showed it to as ‘aggressive’ and I think I toned that back in the bootstrap version by scaling the color saturation back. I’ve also reduced the overall screen footprint by pushing things to drop-down menus. When compressed for mobile, the quest selection does get stacked on top of the content, but I don’t see any way around this short of making it too small to use on mobile anyway.

It was pointed out to me that many users like boundaries because it gives them less to think about, so I’ve decided that there will only be two tiers to quests: tier 1 are the quests that fit the three categories of Main, Side, and Repeated, but with the first two categories having a tier 2 composed of sub-quests/tasks for more granularity. This is a little easier for everyone to wrap their heads around than sub-quests that run indefinitely.

Once I get some good layout stuff determined, and I’m settled with the customization on Bootstrap, I’ll write a little Javascript to play with context and form state, hopefully it will translate well to the final product when data will be pouring in via AJAX and PHP.

  1. Second pass at design layout with Bootstrap in mind (HTML and CSS)
  2. Bootstrap customization for metro look and appropriate colors (LESS CSS compliation)
  3. Recreate new design using Bootstrap (HTML and CSS)
  4. Created drop-downs from Bootstrap framework (CSS, Javascript, jQuery)
Posted in CSIT2230 | Comments Off on Javascript: A Shot of Caffeine

CSS: Built with Style

CSS Quiz



Link to site:

On my last project we did bad things with CSS. There were two master pages for the pair of layouts we used, each with a different embedded style sheet. Each page and Custom Control had it’s own style sheet, nothing was standardized except the layout and the convenience of Custom Controls.

I want to do things different this time. For one, removing pages from the mix of the final project. If the page is designed right, all application functions can be performed from one page built to handle a current context. Next, a single style sheet with classes for the common components (.ascx files aren’t going to be available, so it’s important to get repeated components classed out right).

My splash page was mostly a proof of layout, without a lot of substance, but over the course of the week I’ve poked it into a reasonably good looking shape, awaiting scrutiny of people I trust to give me the truth. I’m on the fence about whether the charms should be on a right sidebar or in the footer, so for now I’m going to keep them in both places. Eventually one of them will be phased out.

I’m ready to start Javascript. The page design will become clearer when I start working with it and when it becomes more prominent. The HTML of the Main Content and the left menu is context driven, rather than being pushed by pages. Just the same, I’ll make two views I’ll put into separate pages to build the look.

It also has a name now, BreadKnot. I’m going to try to build the reward system around a bread making theme with the help of my sister who is a fantastic baker. The idea being that this is about tasks, like recipes, and it’s about personal growth, like the transformation of ingredients into bread.

  1. Created Header and Login(HTML, CSS)
  2. Created Views Menu and Menu Items (HTML, CSS)
  3. Created Quests Menu and Menu Items (HTML, CSS)
  4. Created Mock-Up Charms Bar(HTML, CSS)
  5. Created Definite layout (HTML, CSS)
  6. Created Two Color Scheme with Accent (HTML, CSS)
  7. Created Common Styles (CSS)



Posted in CSIT2230 | Comments Off on CSS: Built with Style