←
→

eye of the storm

Filed Under Category Education, News by titanium

Dear BBC, in your recent article about Facebook’s changes to their privacy settings, you mentioned that:

Over recent weeks, Facebook has been in the eye of a storm

I think you mean something like: “have been in hot water lately” or “have been under fire by privacy advocates” or something like that. You see, the eye of the storm is the eerily calm centre of a hurricane/typhone/cyclone.

1. A region of calm weather right in the middle of a storm.
[All Words.com]

(meteorology) The center of a tropical cyclone, marked by relatively light winds, confused seas, rising temperature, lowered relative humidity, and often by clear skies.
[Answers.com]

If you mean: right in the thick of inclement weather, don’t say eye of the storm. Yes, that is the middle of the storm but it’s not good English because the meaning is confused. Use another phrase please.

May 27, 2010 | |

COMMENTS

FIT2001 week 11: don’t scare the users

Filed Under Category Tech, fit2001 by titanium

I don’t know if this topic is nicer than last week’s topic, or that I forgot to take a proper “stand up and walk around” break between the hours during the first listening of lecture today, or the fact that I had 4 slides per page lecture notes (rather than nicer 1 slide per page lecture notes) for lecture 10, or that the happy-sense of catching up to where I need to be is colouring my view; but I liked this lecture better.

A lot of what is covered in this lecture is also covered in another class I’m taking this semester: FIT3084 Multimedia Programming and the WWW. Check out the lecture notes (not slides, it’s a web based subject) on Human Object Interaction and Human Computer Interaction for some more information on affordances, etc.

Alison’s paraphrase of the lecture:
To the user, the interface IS the system so we need to design it so they don’t think our system is bad. As David Pogue said: Simplicity Sells. (Thanks for showing us that POD. Also recommended is David on the Music Wars.)

We need to care about what the user will Use (physical aspect) see/hear (perceptual aspect) and know (conceptual aspect). The user interface extends beyond the screen and input device, to ergonomic details as well. (I hadn’t realised that the lack of a camera in the iPad could be because the way people hold an iPad most naturally means the camera shoots up your nose!)

HCI, or Human Computer Interaction, has lots of fields that influence it. I thought there was a small dig at Multimedia people “who claim they’re experts in design” which was amusing. I think it interests me because it is a broad field, and I’m a broad kind of person with my literature/language/children/computers/etc interests. Or Double Degree.

Metaphors are very important in User Interface Design, because it will dictate how the system looks and how the system interacts with the user. The main metaphors we use are:

Metaphors give us power in design because we don’t have to start at square one in making the interface user friendly, by following standards. (I liked what David Pogue said though- intelligence trumps consistency. If it makes sense to break tradition, then break it.) Users should only need to learn something once and then be able to transfer that knowledge: file-save is an example of this. (Broken by Balsamiq because of a limitation to the medium, perhaps.)

So what are visibility and affordance? Visibility is the concept that you should be able to see all the controls and get feedback that something is happening when you do something with the system. Affordance is designing things so that how to use them is obvious by looking at them. A door with no handle but a metal rectangle instead is clearly for pushing, not pulling, for example. These two concepts sum up the eight principles of design, which are:

Similarly, here’s another list of this gelled down into six principles of interface design that I compiled for FIT3084.

Be aware that the user perception of the system differs from the analyst/designer perspective of the system! Don’t scare the users, pick a standard (for fonts, colours, etc) and stick to it. Play with screens, story boards (user flow diagrams), prototypes and UML diagrams (the UML diagrams not so much. Know they exist but pick a cooler way of designing interfaces for your own sanity.)

Be careful with just sketching stuff on paper as you might be designing stuff that’s really hard to implement: an example of this is the FIT3084 multimedia assignment: we designed a slider into our interface, only to find that HTML doesn’t have a slider built in. Using a tool helps limit you to what’s available.

Designing for the web is harder than designing a straight software interface because it takes more effort to implement what you want, there are no standards to follow to keep the user happy, and the tech that you choose isn’t identical across all your user systems. (Designing for the web is fun though, and might be the future?)

I definitely will try and get a copy of “The Design of Every Day Things” by Donald Norman to read, but maybe after the exams are over.

The Tutorial
Was a short tutorial, lots of time spent looking at the the assignment 2. We’re focusing on the “attempt quiz” use case. I didn’t look at the exercises at all, but will probably scope them out when I’m working on my assignment.

The Quiz
Lots of stuff I already knew or could guess the answers to.

Hooray, caught up with blog, with the lectures, and have made good progress on my homework. Still got three things due next week, but oh well, such is uni life.

May 21, 2010 | |

COMMENTS

FIT2001 Week 10: object oriented design

Filed Under Category Tech, fit2001 by titanium

So week 10 was a bit of a nightmare, with the Assignment 1b due for FIT2001 kicking things off, followed closely by Project Management 1b and 1c due (thankfully extended from Monday to Thursday) and a large essay due for Critical Theory (extended from Wednesday to Monday) as well as a Girls Brigade camp (horse-riding in Daylesford) that I was going at the weekend! I had to write the essay while on camp (and into the wee hours of the morning as Sunday turned into Monday.) I enjoyed writing in the country air, it was actually kind of fun. To top all that busyness off some inconsiderate soul had ventured into public while infected with a cold (ARGH) and I happened to pick it up. (Seriously people, take one for the team and stay home if you’re sick.)

Hence my blog post (and catching up with the lecture) for this week have been pushed back, and now I have to do double time to catch up.

Thoughts about Lecture

To be honest I wasn’t blown away with the lecture this week, perhaps because I’m not in the routine of listening having skipped a week, or perhaps because it actually wasn’t that exciting. It boiled down to Object Oriented (OO) stuff we’ve covered before and System Sequence Diagrams which we’ll need for the assignment. I suppose the OO stuff would be very exciting if you hadn’t encountered it before, but we’ve been steeped in OO since we walked into the first Computer Science (sorry, Faculty of IT) lecture.

The system sequence diagrams look logical which is good- I’m a bit anxious because POD says we should practice them or they won’t make sense, but hopefully I can squeeze some practice in.

Design is about taking the abstract stuff we made in the analysis phase and turn it something more concrete that we can give to a programmer. This means that the design document will be much more technical than the Functional Requirements Specification.

UML (aka ugly messed up language) uses the same kind of diagram for the class diagram for both the analysis and design phase, with slight variations on how you use it. Use caution when you’re looking up examples that you’re looking at Design examples.

Focus on the Use Cases, take each one on in turn. Packages make the diagram prettier, but have a purpose. We divide out the view layer and the data-access layer from the domain layer, these will probably be implemented separately anyway. In the real world often people just glue interfaces to databases and don’t focus too much on the domain layer.

The Tutorial
Well, I was sick, so didn’t make it in.

The Quiz
I know the OO stuff (with just the new wrinkle of Navigation Visibility) which is no big surprise.
POD didn’t refer to guillemets by name, they’re those angle bracket pairs. << >> Easy process of elimination there for the quiz- “I know what all the others are, must be this one!” guillemets indicate << entity >> << control >> << boundary >> << data access >> stereotypes and of course we saw guillemets before with << includes>>.
Lots of UML notation to learn here, which is a bit depressing.

On to the assignment, the other assignment, the other assignment, or the week 11 lecture!

May 21, 2010 | |

COMMENTS

FIT2001 week 9: dealing with crusty IT dinosaurs

Filed Under Category Tech, fit2001 by titanium

This week I was reminded of the best and worst of university. The best: being inspired and excited by ideas. The Identity 2.0 presentation at the end of POD’s lecture was great. (Claytonites and other non-Caulfielders: you can find all the videos on the Caulfield Resource page in Moodle.) Of course, the worst of university comes with a lot of work and not much time. [ Bob the Dinosaur from Dilbert ] I neglected my “learning” a little this week, leaving listening to the lecture to when I was tired and grumpy on Saturday night (yes, I have no life. During uni, anyway) and focused on getting my assignment (the first of 8 due in the next 3 weeks) finished. I finished it off, even having some fun with a letterhead and fake signature for my cover letter. Still, working on assignments is not a process I look forward to.

This week is important to know but not to do, which is nice. We might encounter some dinosaurish systems that are based on Structured Design, or we might encounter some dinosaurs as our bosses who think that Structured Design is the best way to design software. In any case, Object Oriented Design appears to have evolved out of Structured Design, so it might be good to start understanding stuff here.

The old: “jargon means you get paid more” theory has resurfaced, with Cohesion, Coupling (misheard as “cuddling” the first few times on the recording), flags, central transform, and afferent and efferent data flow!

Dilbert.com

The key concepts
Our goal with design is to take the analysis and build software that does what we want it to do in a way that works and works really well. Hopefully the analysts have done a good job and we can use the existing diagrams and reports to build our design documents. The big things we need to do in Structured Design are:

There are two ways of doing this: Transaction Analysis and Transform Analysis.

In Transaction Analysis, we draw an Automation boundary and work out what transactions are happening- what data is going in and out of the system. (We can also break this down and look at what data is being sent over subsystem boundaries.) A nice thing here is that we can know what interfaces are needed and send them off to dedicated design teams and so divide up the labour (getting things done quickly by doing them in parallel) because we know what data they need to get and display.

In Transform Analysis, we take the diagrams and turn the bubbles into squares. We don’t get paid much for saying that, so we call it the CENTRAL TRANSFORM (cue booming voice, thunder roll). Basically we take a high level DFD (not the context diagram, DFD level 0) and turn it into a design diagram.

Modules = procedures = functions, it just depends on what you learnt and who taught you. These are the squares with names in them in the diagram. While we’re talking about modules, let’s talk about cohesion and coupling. We want low coupling and high cohesion. Coupling means when modules rely on each other, so if you change one module it affects the other. This can lead to nasty and unforeseen consequences when you make changes, so it’s a good idea that the modules are as lowly coupled as possible. Cohesion is talking about internal cohesion, not the cohesion between objects. Basically it means that we want each module to focus on one thing and only one thing, and be solely responsible for that thing. Low coupling, high cohesion. (Think school camps- we had a policy on school camps of “joyful glances only” – it was a conservative school. Low coupling. High cohesion- everyone responsible for their own selves but getting along nicely.)
On the cohesion note, I’ve heard some coding style guides suggest that methods should be a screenful size, to help with understandability and also the “just one thing” idea.

Other Stuff:
Control flags are variables that are booleans. (0 or 1, true or false) lots of them can indicate poor quality code, but they can be useful.

While analysis carefully separates out the different data stores needed, the Designer can simply things by lumping them all in a database. It’s good to have modules that deal only with handling the SQL. Colour coding is good to indicate the 3 Layers. When writing pseudocode try and think what language you’re going to use to implement this so that you don’t make life hard on yourself. Write pseudo-java, pseudo-lisp, pseudo-C, pseudo-PHP, etc, so that you can easily convert it into real code when the time comes.

The Tutorial
I found this week’s tutorial really interesting, not that we looked at the actual tutorial all that much- I guess we’ll have to catch that up as we’ll be using it for our assignments. It was good looking around the room and seeing everyone working on their assignments, seeing some diagrams like mine, and others that weren’t. I find the questions that others ask really useful to my own thinking. I also really really appreciate the dedication of my tutor who had a Clayton consultation and also helped me out with my understanding in the tutorials- it was good to say “is this what we’re supposed to do” especially because Visual Paradigm doesn’t have 100% matching with the names of the diagrams. Having a two phase process of asking what I needed to do and then checking I had got it right was important. I put a lot of effort into a high level DFD and had to cut it right back for the context diagram: but I’ve held on to the high level diagram and hopefully I’ll be able to use it in my second assignment. Fingers crossed that things don’t get changed totally for OO Design. I’m pretty happy with my assignment, just have to wait two weeks until I get my marks! However hopefully I’ll get some good feedback from my tutor before then.

The Quiz
The quiz showed that this week is all about vocabulary, as it caused me to stumble a bit. I think I’ve covered everything that threw me in in the lecture and reflection, so I’m pretty happy to leave this until revision time. These are the words that I didn’t know:

The great Moodle Incident!
It all started with an unhappy student who missed the simple left hand navigation bar. A complaint on twitter made me start to notice. A forum post about the South African weather meant that POD posted a quick screen cast on how to minimise campus information. Bingo- our screens were different. Clayton students didn’t have a quick navigation tab system, just a long plain page of html. Screenshots, twitter comments and a bug-fixing POD all helped to get us our tabs. Why didn’t we complain in week 1? I found the site usable, a sight better than Blackboard, and didn’t know there was anything missing. I’m guessing the frustration with an interface builds when you are actually trying to use it for something important: in this case, Assignments. I guess a screenshot of what Moodle should look like would have helped test the system more extensively (Clayton students missed out, but all staff and Caulfield students had the tabs, but no one knew there was anything wrong.)

This blog post complete, I’ve now caught up to my usual schedule. Three big assignments still due next week (one is really a two-part assignment because both are due at the same time) and an icky essay that still needs to be tackled (involving an expedition to the library (Matheson) to hear the hum of the books!) so I won’t be devoting too many brain cycles to FIT2001 until next week. Thoughts with all the people still cranking away at their assignments, if you’re procrastinating by reading this post: get back to work! :)

Still reading? Well, being born only a few years before Dilbert was started, we haven’t had a chance to enjoy some of the earlier strips. The dinosaur image in this blog post is actually Bob the Dinosaur, who wasn’t extinct, he was hiding in Dilbert’s house. Start here at 17th of July 1989, and read about the next 7 to 10 comics. Be warned though, Dilbert is very addictive. Maybe finish off that assignment first.

May 8, 2010 | |

COMMENTS