Some thoughts on internal group project

We started on an internal group project this week. There’s been much talks going around in the form of issues and discussion threads, but not much has actually been committed into the repo itself.

The internal group project basically a re-implementation of an existing system here: http://zenit.senecac.on.ca/~chris.tyler/planet/. This website gathers blog feeds from all subscribed users and put them in one place. It’s easy for someone, for example, a professor, to read all of Seneca student’s blogs in one place without leaving the webpage to visit each site one by one.

https://github.com/Seneca-CDOT/telescope. Here lies the code repo. I’ve started one issue here: https://github.com/Seneca-CDOT/telescope/issues/5 with the purpose of committing some basic materials into the repository to get us started with. I have went over to the old website, reverse engineered the html source code, css and some pictures and put them into the repo in this PR: https://github.com/Seneca-CDOT/telescope/pull/9.

This PR is meant as a starting point of front-end/UI design. It is by no means the finished project, nor did it ever had that purpose. Moving forward, through analysing the html code for the website, people can now change it into a template, replacing the “ipsum lorem” placeholder text with data they intend to pass in. The pictures can be replaced/exchanged, the css can be modified. Even the entire thing can be replace with react/angular or whatever front end technology the want to use.

But the point is, without something to exist in the project to get us started, it’s difficult for people to actually move forward. All the talks are in the air, with people arguing over “react vs angular”, “npm vs yarn” and blahblah. With something concrete, a.k.a. CODE in the repository, people will have something to refer to, and have more meaning discussions with actual content/materials to back up their point of argument.

My second thought is that this is a traditional re-implementation project. Which means, we are building something new to replace the old one, and we are eventually going to decommission the old one. In simplest terms, the new project needs to include all the requirements/functionalities of the old project, plus maybe something new. One phenomenon that I see is that people tends to rush ahead and start designing for the new project, without even knowing the details of all the things that the old project offers. This can result in a product that might have all the updated technology and shiny new looks, but actually one or more of the core functionalities have been forgotten/lost in the move.

Lastly, it is extremely important to involve end users in a project right off the bat. Who are the end users of this project? I actually have no idea. Is it meant mostly for the profs? Perhaps some students? Or can we even extend that further to the alumni? I mean, the website is on the world wide web, which means anyone with an internet connection should be able to visit. Whoever they are, it’s important to involve them, listen to their thoughts and needs, and extract functionalities and requirements from them before we dive nose-deep. However, I don’t see this “user consultation” step being performed at all for our internal group project. I like to interpret the making of this project as a group of programmers/designers sitting in a dark room, who think they have the best idea of what a website should look like for collecting blogs in one spot without the involvement of any end-users whatsoever.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website at WordPress.com
Get started
%d bloggers like this: