education on new feature, was [Invitation] @ Thu Jan 25 22:30 - 23:30 (1 hr)

26 Jan 2007 - 7:25am
7 years ago
4 replies
307 reads
.pauric
2006

I apologize for this, a feature I hadnt noticed before popped up in my
gmail, "add event info"

Being the curious type I clicked it in part of replying to Dave. It
somehow pulled in an account setup by our admin for a group potluck
event in December. I didnt notice - apologies to the group.

Now the question I have, apart from my own carelessness, is are there
any guidelines on introducing features? Specifically I'm thinking
about staging features in with an overly helpful period then followed
by the feature falling back to 'normal'

The reason I ask is I will start 2 projects this year that will bring
fairly complex feature-sets in to the domain of a wider, maybe less
knowledgeable, group of users. Its a natural part of the
commoditisation of these products.

Does anyone have any advice or examples of interfaces that start
overly helpful and somehow grow with the user?

thanks

On 1/25/07, Kevin Wong <kevinwong at kvwong.com> wrote:
> Hmm, it might be just me, but what is this? Sounds fun?
>
> Thanks!
>
> On Jan 25, 2007, at 7:19 PM, Pauric potluck wrote:
>
> > discuss at ixda.org, you are invited to
> >
> > Title: (No Subject)
> > Time: Thu Jan 25 22:30 - 23:30 (1 hr) (Eastern Time)
> > Description: my bad, as I re-read my response to your reply I can
> > see how you thought I might have thunk that I thought you were
> > being harsh. For which I&#39;m sorry (o;
> >
> > I hope IxDA 2.0 (beta) comes with an Omnigraffle plugin feature so
> > all us half dyslexic visual types can communicate more clearly.
> > Speaking of which, how many features will it have and did I miss
> > the Participatory design meeting?
> >
> > p.eace
> >
> >
> > You can view this event at http://www.google.com/calendar/event?
> > action=VIEW&eid=Z2ozODA1NDQwZHViMmVzMTdmNDhqbTdjYzggZGlzY3Vzc0BpeGRhLm
> > 9yZw&tok=MjEjcmFkaW9yZW50YWxAZ21haWwuY29tNWIxZjJiZjUzMGQ2OGMzNjIwNzVkN
> > mQ0MDJiMTI2MTQzZjMxNjZlZg&ctz=America%2FNew_York&hl=en______________
>
>
>

--
Job type: In house
Field: Embedded & physical interfaces. Web/cli

Comments

26 Jan 2007 - 8:05am
maglez@btintern...
2006

It's a complex matter this one that depends on many factors.

Following Agile methods like Extreme Programming (XP) the recommendation is not to over-engineer
so the answer is to first implement the feature as it's needed today and if later has to be
changed, then you change it.

Following Plan-Driven methodologies, you design the feature as it has to be used today and adding
all needed code to support future changes.

Agile methods usually works well for small teams, 2 to 20 programmers, where features requests
change easily due to the business model and/or the project.

Plan-Driven methods are usually implemented within big companies that can afford to spend months
on requirements gathering, many reviews and approvals, back to requirements specifications,
writing documentation, etc. You cannot do this with a project that may change in a short
timeframe, otherwise you would loop on the requirements specifications for ever.

This is on the implementation area, on the final user, it seems that your users are not advanced
neither intermediated users so it's risky to change a feature in a way that looks too differently
to the previous one so design it in a way that it will easily reassembly the future look and feel
of that feature, your users shouldn't get overwhelmed for the new set.

I hope this comment helps you. Let us know some more about the problem, is it at implementation
level? final user level? business level?

Miguel Gonzalez.

26 Jan 2007 - 8:21am
Adrian Howard
2005

On 26 Jan 2007, at 13:05, Miguel Gonzalez wrote:
[snip]
> Agile methods usually works well for small teams, 2 to 20
> programmers, where features requests change easily due to the
> business model and/or the project.
[snip]

I think it would be more accurate to say that agile methods use
development practices that make managing change easier.

You don't only apply agile methods to projects where change requests
are simple. You develop using agile methods to /make/ the system easy
to change.

Cheers,

Adrian

26 Jan 2007 - 9:05am
.pauric
2006

Miguel "I hope this comment helps you. Let us know some more about the
problem, is it at implementation level? final user level? business
level?"

That helps on more complex project, the introduction of a web based
interface in addition to the existing CLI.

However the other project is an OEM product, no direct control over
the day to day development. The box is effectively a linux server
with a web based front end for administration of the mail, voice &
file servers along with things like vpn termination, wireless access
point etc.

In true open source fashion each of the individual features, or
modules, is fairly well designed. However the integrator did little
in the way of designing cohesive flow . For example, an admin can
switch all of these services on but there is no indication they must
first setup user authentication for any of it to be useful. A user
must have an active file share for their voicemail to be saved. Lots
of little gotchas like this.

I was initially tasked with the typical OEM interface work, paint it
company colours and tidy up the usability. But, the more I use it, the
more I realize we may put a significant dent in margins by
inadvertently generating a lot of support calls. I normally solve
this problem with some wizards as config education tools. But my
mistake with gmail/calendar leads me to think there are other
solutions to pro-actively educating users on functionality. Something
along the lines of interactive cheatsheets maybe.

Whatever the solution, the project does not allow for redesigning the
existing screens (they're not that bad) so I need to find a 'bolt-on'
solution.

thanks

26 Jan 2007 - 9:35am
maglez@btintern...
2006

It sounds pretty bad, a unfinished final product, your client thinks it's finished and ask you to
do some small modifications that actually requires a lot since it's not a finished product but a
low quality finished product.

What you need is to implement an interface between the base system and the user interface,
something that properly manage the user's call to the back system, something that doesn't allows
you to call a service without having activated other necessary services but, as you say, that will
put a significant dent in margins, it's a shame.

You probably can intercept the error message system, if any, to catch up those errors and present
alternatives to the user to solve the problem, like when trying to activate a service that needs
some other services, get the error message and translate to something useful for the user.

I doesn't sound to good. Whatever the option is going to cost you.

Miguel Gonzalez.

Syndicate content Get the feed