Hi all,

We've had many installs for the plugins, and I'd just like to get a little feedback on user experience. What worked for you and what didn't? Have you had success using metaABM for working models? Is there an area that was so confusing that you just gave up? What features or changes would be most helpful in making your ABM development process more efficient? Where should we focus documentation / tutorial efforts?

While we are using metaABM heavily internally, reports from other users will help immeasurably in shaping the future direction of the tools and in making the tools more accessible to less experienced users.

thanks,

Miles

Hi Miles,

I am working through the Getting Started and I hit one issue that I am not
sure can be changed. If this tool has a target audience of persons who are
not Java developers, then they may not easily figure out what is going wrong.

If I create an attribute for instance, the properties form allows me to change
the ID, Label, etc. If I change the ID to have a space in it, and do not modify
the Label, suddenly my code cannot compile. Obviously the ID is the problem
since variables cannot have spaces. But, if I were to modify the Label and
not the ID (only on the initial time) then the ID is created correctly. The
Label is formated to create the ID. I believe that the functionality that is used to make
sure the ID is generated/saved correctly this first time when only the Label is
changed should be used to verify the ID when it is being changed in all cases.
Or something along those lines.

Yeah, I can see where that would be an issue for first time developers. Here is the general idea..

1. Label is human-readable label, ID is as you inferred is a Java-like identifier.

2. As long as Label "matches" the ID format, any changes to label will be reflected in the ID.

3. As soon as you change ID that no longer happens, the assumption being that you want to have a different ID for some reason.

So right now it is possible to define an ID that isn't a Java identifier. (Java isn't the only target as we want to be language neutral, but this is still something we should enforce.) I suppose we could simply make ID an "advanced" feautre and hide it from new users, but the best solution is one of the features we haven't yet implemented, which is using the oAW system to check/validate metaABM edits. The current EMF.Edit stuff is designed to *help* the users make correct choices but doesn't actually enforce them right now. When we get this implemented you would see an error marker when you enter a bad Java identifier, just as say if you had a syntax error in a Java application.

Hi Miles

I have two minor suggestions:

1. I believe the Grid for the model should allow the user to set
either the cell or cell agent size. I am not sure if there has
been a limitation to this based on possible limitations with Repast
but it would be useful for Ascape generation. I am not sure if this
makes sense in all Grids, but it may make sense in all Grids
generated for Ascape.

2. One thing that may be help for future reference documentation
would be to state what each menu option can do. That may be obvious
to many, but for beginners like myself, I am not sure what exactly
I gain in certain circumstances.

Also, I *believe* that somewhere in the Getting Started you stated that
not all menu options are valid in all circumstances. That you need
to spend some time updating the menus to limit the available options
to only options that make sense within the context of when they are
being called. Do you have an ETA of when you think this will happen?

Thanks so much for all of your responses.

ev

Hi!

1. I believe the Grid for the model should allow the user to set
either the cell or cell agent size.

The issue is not so much various platform implementations, but separation of concerns. That is, the core model is only intended to represent modeling issue per se, not presentations issues like displays and so on. So sorry, you will have to rely on whatever model configuration capabilities are in your platform of choice. At some point we would like to support that kind of runtime configuration but that would be in a seperate meta-model.

You may fairly point out that we do support Styles in the core Structure meta-model, allowing users to create rules that specify how agents are graphically portrayed in visualizations. This is admittedly an edge case and it may make sense to move that in to a separate package at some point, but at this point I felt that that would create a little too much indirection. Also, I felt that in the very common usage of a non-programming modeler who wants to interact with a model directly, it makes sense to treat the semantics of color and so on as directly as say Agent names, etc.. We could add Graphic Functions to support *relative* scaling of graphic figures so that say one agent appears smaller than another, if that would be helpful.

2. One thing that may be help for future reference documentation
would be to state what each menu option can do. That may be obvious
to many, but for beginners like myself, I am not sure what exactly
I gain in certain circumstances.

Yep. We really need to bulk up the usage documentation (such as it isn't ) in general. What menu options do you mean specifically, the context (right-click) menus or something else?

Also, I *believe* that somewhere in the Getting Started you stated that
not all menu options are valid in all circumstances. That you need
to spend some time updating the menus to limit the available options
to only options that make sense within the context of when they are
being called.

Hmmm..again I'm not sure what menus we're referring to..

In the chivalrous way wow gold , we like back to the ancient river's lake. wow gold a good experience as a river of ancient people up. Dofus Kamas ancient chivalrous man, xia female people it is how to make the river's lake.