[Cs5500] Improved UI design

Fri Dec 2 10:26:07 EST 2011

Hello class.

Our user acceptance testing is over. We have failed in one aspect of our
user interface design as described below.

In the remaining week we need to improve this interface to make it very
simple.
I propose that we implement option A described below.

I would like to make Srinivas the designer and implementor of this
interface change.
Is this ok with you? It involves writing scripts that automate the
registration process.
Maybe Karan can assign someone from team navi to help.

Send me a plan today.

-- Karl

---------- Forwarded message ----------
From: Karl Lieberherr <lieber at ccs.neu.edu>
Date: Fri, Dec 2, 2011 at 10:16 AM
Subject: Re: [Cs4800] Error continued:
To: Tom Fiset <tmfset at gmail.com>
Cc: cs4800 at lists.ccs.neu.edu

Hi Tom:

thank you for your message. I think you have spoken for many in the class.
I agree with your assessment that "I should have to run a single command to
run my avatar."

There are two parts to the interface design for our system to test and
evaluate algorithms and claims made about them:

1. An avatar needs only 4 methods: propose, oppose, provide and solve.
Those    methods need access to the configuration information of the
playground.
2. There is a procedure to insert an avatar into a tournament of a
playground and give it access to the configuration information.

Those interfaces should be as simple as possible. I think we have succeeded
with 1.
Or can you simplify it further? Remember, the approach is general and
should work with any kind of algorithmic problem.

We have failed with 2 and apologize for that. There are various options for
2.

A. Liz and others suggested that the only activity for 2 should be to
submit the
a jar file to an svn server. And then it will be inserted automatically
into a
playground. This works well when we require all avatars to be written in
Java.

B. The option you describe: one command in a specific directory without any
additional requirements after download of the playground.

====
You indicate, maybe I misunderstood, that winning a tournament has nothing
to do with "my own ability to code the correct algorithm correctly or
efficiently".
If you meant that, I disagree with it. I make the following claim and I
look forward to see any refutations: All those winning avatars who tied at
the top are bug-free.
The refutation protocol is: Show me a bug in one of the winning avatars who
tied at the top.

My claim is a bit dangerous and my confidence in it is only 90%. But I
think those
tournaments do a very good job in testing the kind of algorithms we
developed.

Again, thank you for your effort to bring out the weak points of our system
explicitly and for describing what you want.

-- Karl

On Thu, Dec 1, 2011 at 11:11 PM, Tom Fiset <tmfset at gmail.com> wrote:

> Ok.
>
> I have tried everything you guys said and it still produces the same error.
> I'm trying not to freak out about this, but this SCG thing is really
> starting to piss me off. Why is it even possible for me to get this error?
> It just seems lazy to me.
>
> TO WHOEVER IS DEVELOPING THIS:
>
> The users of this software SHOULD NOT have to be held accountable for so
> many different and arbitrary setup steps. It's completely ridiculous that I
> should have to do anything other than run a single command to run my avatar.
>
> By putting so many of the configuration steps in the hands of the user you
> open the door for ridiculous errors like this. Every additional step that
> is required (and often not reported to the users in any consistent way)
> makes it that much easier for us to fail at using your software.
>
> Normally I would understand letting people figure it out on their own, but
> we are being graded on this. The success of my avatar has AT NO POINT in
> any of these tournaments had anything to do with my own ability to code the
> correct algorithm correctly or efficiently, which is what this was supposed
> to be a metric for.
>
> So here's my proposition: include a shell script in the build to do
> everything currently required of the user:
>
> ./scgScript build
> ./scgScript runServer root
> ./scgScript runAvatar tvtennis.ccs.neu.edu user password 1
> (uses a random port)
>
> This does not mean I have to change to the bin directory. This does not
> mean I still have to manually copy something. These are literally the only
> three commands I will ever use or need in order to run your software.
>
> Also, it is important to document it all in the same place *consistently*and where everyone can find it (not that the steps will ever change). This
> means I don't have to search through email archives to find out what the
> new run command is (again, not that it should ever change).
>
> If these are the only three steps that anyone ever has to do, there will
> no longer be confusion over what step was missed and ruined everything.
> This also has the benefit that it can be modified for different versions
> and the user will not need no need to learn a new way to get it working.
>
> Please excuse my tone, but this is pretty fundamental concept in UI design.
>
> - Tom Fiset
>
>
> On Thu, Dec 1, 2011 at 6:18 PM, James Antonius <antonius.j at husky.neu.edu>wrote:
>
>> Yes, I just tried it too (using r70) and it worked fine. I think you just
>> need to copy the demeterf jar, hamcrest jar, and Playgroundconfig folder
>> from the GenericSCG folder to the bin folder..
>>
>>
>> ~James Antonius
>>
>>
>> On Thu, Dec 1, 2011 at 6:13 PM, Adam P Belcher <belcher.ad at husky.neu.edu>wrote:
>>
>>> I think you just need to copy the Playgroundconfig folder from the
>>> GenericSCG folder to the bin folder.
>>>
>>>
>>> On Thu, Dec 1, 2011 at 5:49 PM, Tom Fiset <tmfset at gmail.com> wrote:
>>>
>>>> Can someone verify that I'm not insane? I've been trying to just run
>>>> two Baby avatars against each other but I get the same error every single
>>>> time:
>>>>
>>>> Error:
>>>>  ** Type 'exit' to shutdown: GET REQUEST11111
>>>> Exception thrown while parsing: csp.CSPConfig cannot be cast to
>>>> hsr.HSRConfig
>>>>  !! Exception: null
>>>>  !! StackTrace:
>>>>  -- scg.net.avatar.PlayerServer.createResponse(Unknown Source)
>>>>  -- scg.net.avatar.PlayerServer.playerResponse(Unknown Source)
>>>>  -- sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>  --
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>>  --
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>  -- java.lang.reflect.Method.invoke(Method.java:616)
>>>>  --
>>>> edu.neu.ccs.demeterf.http.server.ServerDispatch.handle(ServerDispatch.java:75)
>>>>  --
>>>> edu.neu.ccs.demeterf.http.server.ServerThread$DispatchThread.run(ServerThread.java:130)
>>>>
>>>> STEPS TO REPRODUCE:
>>>> svn checkout svn://svn.code.sf.net/p/generic-scg/code-0/GenericSCGGenericSCG0 -r 70
>>>> svn checkout svn://svn.code.sf.net/p/generic-scg/code-0/GenericSCGGenericSCG1 -r 70
>>>>
>>>> In each directory run:
>>>> java -cp .:demeterf.jar:hamcrest-all-1.3.0RC2.jar demeterf
>>>> src/hsr/BabyAvatar/hsrAvatar.cd src/hsr/BabyAvatar/hsrAvatar.beh ./gen
>>>> ant
>>>>
>>>> and copy the demeter and hamcrest into the bin folder
>>>>
>>>> Start the server:
>>>> java -cp .:demeterf.jar:hamcrest-all-1.3.0RC2.jar scg.admin.Admin root
>>>>
>>>> connect each avatar:
>>>> java -cp .:demeterf.jar:hamcrest-all-1.3.0RC2.jar
>>>> scg.net.avatar.PlayerMainHSR $1 $2 $3 $4 $5
>>>> ./Playgroundconfig/scgConfig_hsr.txt ./Playgroundconfig/hsrDomain.txt
>>>>
>>>> where $1 is port# $2 is astroblaster.ccs.neu.edu $3 is username $4 is
>>>> password $5 is tournament id
>>>>
>>>> It's really starting to get to me, is anyone else even *using* r70 of
>>>> the scg? If so can you recreate this or tell me what, if anything, I'm
>>>> doing wrong here?
>>>>
>>>> - Tom Fiset
>>>>
>>>> _______________________________________________
>>>> Cs4800 mailing list
>>>> Cs4800 at lists.ccs.neu.edu
>>>> https://lists.ccs.neu.edu/bin/listinfo/cs4800
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Cs4800 mailing list
>>> Cs4800 at lists.ccs.neu.edu
>>> https://lists.ccs.neu.edu/bin/listinfo/cs4800
>>>
>>>
>>
>
> _______________________________________________
> Cs4800 mailing list
> Cs4800 at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/cs4800
>
>
-------------- next part --------------
HTML attachment scrubbed and removed