MyInnoQBlog

Besides thinking about how to model my database I continued working on the UI:

Ok, maybe you don’t see that much difference since the last mockup, but I refined most of the div-structure beneath the surface and did some minor design changes.
But the biggest improvement is, that the calendar is now based on real dates. I must admit that the calendar helper plugin helped me with the code.

The bullet-points on the 28th are a representation for all calendar fields, where you entered any hours. If you didn’t enter an other number than 0 the day cell stays empty (for display). If you want the add or modify hours on a particular day, you click the cell and via an in-place editor you can enter your information. (That’s the plan).

I’m not quite sure if the coloring of the weekends will stay that way…I think I’ll decide later, since this is not the most important decision to make.

Now I think I should concentrate on the real app, meaning all the functionality and model behind the UI.

I altered a part of my ER-Model concerning the implementation of the time-reporting:

There’s no longer an entity called “Arbeitszeit” (working time). All the worked hours and days should now get stored in the extra many-to-many-table that’ll be created in between “Stundenzettel” (timesheet) and “Projekt” (project). That table might have the following attributes: StundenzettelID, ProjektID, workingTimeTotal, dailyTimes, notes.
So far I’m not sure how to store all the hours to their corresponding days in dailyTimes (because that’s at least about 30 values every month and user), but I might use a plain text field which contains a somehow-delimited list of working-hours (ascending from the 1st to the last day of the month).

The “Mitarbeiter” (co-worker) entity is also the applications entity for storing login- and user-information.

What you see on the latest mockup, is in Rails the update- or new-action/view for the “Stundenzettel”-controller. I think there won’t be any implementation of a read- or delete-action for “Stundenzettel” (timesheets).

So, I hope this will work for me…

And yes, next time the ER-Model will be in english, too, that I don’t have to bother you (and me) with this language mix. I also code in english, so this makes sense anyway.

[UPDATE]

After talking to Tim and Phillip and considering Stefans Comment, I think this is the right way of modelling the Entity Relationship:

So, in the DailyReport entity there is the attribute Date which is an additional primary key to the ProjectID and the UserID. This way the WorkedHours are stored for every day. So you have a table for every day, employee and project.
The same with notes. This may be useful to describe your tasks on that day, for example. This way I think I’ll have to reengineer the UI, ‘cause notes do not get stored on a monthly basis. I already have something in mind for that.

[/UPDATE]

The second mockup of the applications UI. I thought I stick to the design of innoq.com, so co-workers are somehow familiar with the layout. The (div-)structure underneath is quite different than the one of innoq.com, but I copied some design-elements so far.

Take a look:

In the top-right corner you now have the ability to add one or more projects you’re currently working on. They’ll be differentiated by colors. In the calendar you’ll find the corresponding fields for these projects. Again: I think I’ll hide most of these field in normal view, using an in-place editor.

I’m still really curious what your opinion is…

As far as Unified Process is concerned, I already clarified some of the Business Modeling and Requirements a few month ago. See my blogposts here and here.

Well, I think I had a flash of inspiration: in order to “get real” I decided to start with the project. Isn’t that great?
And I decided to go with the UI first, because the first thing that comes to my mind is how the app will roughly look like. As a working title I called the app “innoVoice” (Yeah, it really is a great pun *cough*)

There you go:

That is the first screen for the colleagues out there in customer-projects for doing their time-reporting.
Ok, it is still made up of standard fonts, there are no fancy graphics etc., but I think it represents the image I have in mind when I think of that part of the app.
What bothers me a bit are all the input fields in the calendar. I think I’ll hide them using some AJAX in-place editors, so they won’t be that distracting.

I don’t really know what will be next. Either I start implementing this feature or I go for another UI-mockup. Maybe I’ll know more in one hour or so…

Stay tuned and feel free* to comment on the UI-mockup!

*actually, I would force you to comment, if I could!

The first draft of what my diploma thesis will be about (in german): Arbeitsthese (PDF)

"Requiring X years of experience on platform Y in your job posting is, well, ignorant."

DHH on the 37signals blog.

I found this post really interesting (including the comments).

As a student I never applied for a job that required X years in experience on a specific platform, but I sometimes wondered how hard employers insist on such a point on a job offer.
I mean, it really depends on the single person. There a definitely programmers (not to say geeks ;-) ) that are better in programming X after one year of experience than others are after - say - 3 years (IMHO).

What do you think?