Hey all,
I would like to know how you design you tool before starting to program.
For the moment I am doing everything on paper first with some supporting images. And I make a quick drawing and ask feedback to an artist to know if the UI is something the artist would use. Then I write down all the core feature with the priority number on the top of my code file.
I always try to have the same code structure for every tool. This is something I always construct in the beginning so my code stays clean.
Every time I start on a core feature I first plan it on paper and then develop it with pseudo code. This way I already got some comments for other programmers and myself. When I am glad with the pseudo code I start developing the real code.
- Do you use any software for planning out your tools?
- How much planning do you do before starting to code?
- How much attention do you give to the UI in the beginning? First some dirty development UI or directly something you want to test out for the artist?
- What do you do when you have to develop a tool with someone else? What necessary things have to be done to get some good teamwork?
- How fast do you give you first version of the tool to the artist? And is this something you already decide in the beginning when designing the tool?
Regards,
Nysuatro
We mostly write smaller scripts and tools here with a maximum of 3 to 4 TAs involved, with most TAs coming from an artist background.
The ui is pretty much the most important thing when we make tools for artists (as opposed to making it for other TAs). It often depends on a good ui if the tool will be used at all/used correctly/liked by the artists. I prefer when people like using our tools because then they’re more inclined to give feedback and less inclined to not use the tool or use work-arounds so they don’t have to use the confusing ui.
The ui also determines how much control people have over the underlying tech. Sometimes in order to keep the ui simple you have to make your script cleverer - e.g. it assumes clever defaults, it finds out information itself which the artist normally has to provide, etc. This all adds to the coding work.
So usually before coding we think about:
- what does the tool have to do (prioritize core functions)
- how will the artist use it
- which non essential features can we strip down for a more streamlined user experience
Basically we’re dumbing things down (hey, it works for Apple )
Make one tool that does one thing really well with a simple intuitive standardized ui.
After all this we have an idea which modules we have to code.
Sometimes we mock up UIs in photoshop/Qt Designer together with a screenshot of max or maya so people get an idea how it will look in action. Depends how complex the tool is. For smaller scripts paper is ok.
If we can make tools so they can be bound to a hotkey/shelf button then this is always preferrable over a ui.
For working with other people - make sure they’re using the same coding conventions you use. Many TAs are not coders, so without preparation the code will be quite messy. This also means some TAs have a more difficult time reading other TA’s code - so comment the code. Make sure everyone knows the priorities and what they’re supposed to work on. Have some way to manage your code when working with multiple people (P4, etc).
Having a UI style “handbook” helps where you lay down some rules for making new UIs. Having a unified UI really helps artists to use new tools, because they behave similar to tools they already know.
We usually involve the artists rather late for testing. Since many of them don’t speak English it’s sometimes rather difficult to get focused feedback in an easy manner. Plus we have people with art production background on the team. But I guess it mostly depends on your tool / timeframe how much you need to involve other artists.
Thanks you for your response RobertKist
This is all very interesting.
Usually work on the underlying components first keeping any data separate then mock a UI and roll it out for test, usually gives complete flexibility for change if there’s feedback.
We do try and make things headless chicken proof as the last thing anyone wants is to have to THINK and about the tool that’s helping them achieve the goal they have in mind.
I’ve worked with this team for a fair while so… you get a feel for what’s acceptable based on knowing the individuals and their natural software use age patterns.
I looked at it when it was first released and had a chance to play around with it a little bit. Most of the advanced design modules which I was interested in (like CFD) require proprietary licenses and you have to pay for them. But the VLM and DATCOM portion is free.
The software is definitely in advanced stages but what kind of disappointed me was the cookie cutter methodology to airplane design; meaning that you can’t go out of the box and design something a little bit out there.
In terms of preliminary design and starting from scratch I think its definitely an interesting package. If you get a chance to play with it some more, let me know what you think? I would definitely be curious to hear.
Hope all is well!