The future policy for dealing with user feedback?

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Tue Jun 10, 2003 9:46 am

Jamesk and NateTG, (from what I can tell) this is pretty much exactly what Ton was asking for in a 'functionality board'. From the thread he posted, he wasn't sure that there was much positive feedback and support for it, but now it seems there is. I'll talk to him tonight and see what his ideas are for how to progress.

NateTG
Posts: 37
Joined: Mon Oct 14, 2002 2:38 am
Location: Here

Post by NateTG » Tue Jun 10, 2003 9:54 am

I agree about starting at elYsiun. Also, a forum would have to be well organized, as you say, with feature requests in their own topic, and with guidelines for posting. we should probably announce it on Elysiun Chat, and see if we can get enough support for the idea.

I think this would be easier for both the coders and the users, as the users would know exactly where to go with their feature requests, and the coders would have access to a "refined" list. I don't know exactly what you envision. I am thinking a periodic (monthly? biweekly?) published list of current feature requests. We would certainly need coder types to assist in weeding out ridiculous requests and in helping us lay out a clear "feature plan."

If we have sufficient manpower, I think it will be very beneficial to the blender community. Especially if we can get coder cooperation.

The way I see it our course of action would be to:
1) Announce on Elysiun chat, and see what support we get
2) If support is sufficient, (I would say a team of at least 9 would be needed if we want to prepare a cohesive feature list) request a special forum on Elysiun
3) See where it takes us.

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Tue Jun 10, 2003 10:04 am

Feature requests are already easy for people to submit via the tracker. Setting up a group for people to think about cool features wouldn't be that valuable - it's easy and it happens enough already. The real value of such a group would be in figuring out how those features could fit into Blender. This could involve researching how similar things are done in other programs and identifying positive and negative points, coming up with new functionality/interface ideas, looking for ways in which features could be implemented in Blender that is consistent with the way other features in Blender work, and so on. It could also involve identifying problems in the current way that Blender works and offering solutions that are more sueable, functional, and so on. This is what is really needed - particularly the research and reasoned debate.

As an example, recent tuhopuu builds have coloured wireframes. It's easy to say as a feature request: "Blender should have coloured wireframes", but it's much harder to research and think through all the associated issues: On what criteria should objects have different colours? Should the colours be user-defined? How do the changing colours affect or dilute the impact of selection and deselection in Blender (since the major feedback for selecting an object is that it turns pink)? Are there any potential dangers or misuses of these different approaches? Can we get ideas of what and what not to do from other programs? Are these ideas applicable to Blender? etc. etc. etc.

These are the discussions that need to take place, with both coder and artist input. Right now, it's mainly just the coders, mainly based on opinions and personal preferences, with very little research into such matters. I think this is not the best solution, and it is what a functionality board could really help with.

Jamesk
Posts: 239
Joined: Mon Oct 14, 2002 8:15 am
Location: Sweden

Post by Jamesk » Tue Jun 10, 2003 10:10 am

a forum would have to be well organized, as you say, with feature requests in their own topic, and with guidelines for posting.
Most certainly so. It would cleanly solve the problem with 'request scattering' we've got now.
I don't know exactly what you envision. I am thinking a periodic (monthly? biweekly?) published list of current feature requests.
I have not thought about that in detail yet. But some periodicity is probably good. Maybe deciding the exact intervals should be dodged until we get some idea about the amount of requests. It is probably a good thing if the refined lists are not too massive.
We would certainly need coder types to assist in weeding out ridiculous requests and in helping us lay out a clear "feature plan."
Agreed! There are some guys that appear to "swim safely" in both these environments, so someone like that would be good. The only name that comes to mind right now is Cessen, but I'm sure there are others.
Any takers here?
The MasterPlan wrote: 1) Announce on Elysiun chat, and see what support we get
2) If support is sufficient, (I would say a team of least 6 would be needed if we want to prepare a cohesive feature list) request a special forum on Elysiun
3) See where it takes us
I'm off to do a bit of work now, but we can figure out an announcement later, yeah? Feel free to drop me a mail, everybody.

Jamesk
Posts: 239
Joined: Mon Oct 14, 2002 8:15 am
Location: Sweden

Post by Jamesk » Tue Jun 10, 2003 10:15 am

broken wrote:The real value of such a group would be in figuring out how those features could fit into Blender. This could involve researching how similar things are done in other programs and identifying positive and negative points, coming up with new functionality/interface ideas, looking for ways in which features could be implemented in Blender that is consistent with the way other features in Blender work, and so on.
Agreed. We would have to make sure that any worthwhile request goes through these steps as well.
These are the discussions that need to take place, with both coder and artist input. Right now, it's mainly just the coders, mainly based on opinions and personal preferences, with very little research into such matters. I think this is not the best solution, and it is what a functionality board could really help with.
Most certainly. We need organised input from everybody - maybe it all converges to the functionality board before being dispersed to the coder community.

NateTG
Posts: 37
Joined: Mon Oct 14, 2002 2:38 am
Location: Here

Post by NateTG » Tue Jun 10, 2003 10:20 am

broken: that, I think, is what we are proposing- a group to organize, research and "refine" the scattered feature requests that exist. NOT a group to think of cool features; plenty of those exist already. Ideally the group would contain both coders and artists, producing the blueprints of features.

It is different from the FuBo (which I didn't finish reading, mostly due to thorax) in that it is not intended to be part of the blender "administration." It is more of an organizational proposition.

NateTG
Posts: 37
Joined: Mon Oct 14, 2002 2:38 am
Location: Here

Post by NateTG » Tue Jun 10, 2003 10:21 am

three times in a row, someone has posted WHILE i was writing my post. :lol:

Jamesk
Posts: 239
Joined: Mon Oct 14, 2002 8:15 am
Location: Sweden

Post by Jamesk » Tue Jun 10, 2003 10:31 am

NateTG wrote:three times in a row, someone has posted WHILE i was writing my post. :lol:
Gaah! I had that too - don't you just hate it when that happens? :D

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

I have a better idea, check out UMARK!!

Post by thorax » Tue Jun 10, 2003 11:46 am

ITs a great Idea.. And better yet it would be implementable
int blender, and very easy to do.. Its amazing I can get to be right on time for once with an implementation that works, is multi-lingual (graphical) and allows for any user to document blender,
add feature requests (which they are in the context of the problem with blender!), wihout excessive descriptions, lots of text and feature request listservs, etc..

I'm hoping this gives people some ideas..

The power of prototyping, yeeeehaw!!

Well I can do a design for blender that describes
how to incorporate this feature into blender.. if all you guys are still confused.. I figure this feature could be added to blender immediately just by taking every functional event in blender and associating a database query with it througha web page URL.. It would also
help some of the newer blender users to find information in the website without using the poor interface of a word search on a database..
Its alwasy easier to just do a query by feature..

Also it would be possible to describe a tutorial as a series of button clicks
and actions then use the button queries to find the tutorials that include them, all without the user having to speak a word of english..

That is what is needed in blender..

ton
Site Admin
Posts: 350
Joined: Wed Oct 16, 2002 12:13 am
Contact:

Post by ton » Tue Jun 10, 2003 2:27 pm

I can also be of help. Either with a designated mailist, or a forum here.

Adding more forums here is being evaluated now... there are too many i think.

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax » Tue Jun 10, 2003 3:12 pm

Link to UMark example

(edit by broken: I fixed the link code, so it doesn't span 5 or so page widths. Please remember to preview your posts.)

Click on the link above and wait about 15 seconds if you have a modem..
The Image that is generated is rendered in PHP in realtime.. I
created the hand/finger images without producing a seperate
image.. The Sole purpose of this PHP script is to allow users to
reference features in the interface and place them with their
messages, as I've done here.. The URL above is actually an encoding of
the particular image references and a set of commands that draw
index-pointing hands on the image.. The idea is to allow the user to point to features in blender's interface and the inverse of this is to be able to
make a database query for at the very least documentation of features in
blender. I'm not suggesting we use UMARK, but I am suggesting that
to document blender better it might help to be able to bind with keys and actions and hotkeys in blender a special code that is sent to a function
that calls a webpage which would query the database for help..
The same query could be used to enter in feature suggestions,
submit bugs, and so on.. Then the database could be analyzed to see
which feature has the most requests, most bugs, most documentation,
most enthusiasm, etc..

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax » Tue Jun 10, 2003 3:49 pm

Jamesk wrote:
eskil wrote:
Ton's suggestions for a Functionality Board was maybe (sort of) along those lines, but I'd be willing to organize a "BUIG" if there's enough people around willing to participate. Such an interest group would gather input from 'regular, non-coding users', clean it up and produce detailed descriptions of desired features and tools. It would result in some sort of RFC's or 'recommendations' along with as much technical data as possible to pass on to the coders.
Those RFC's would of course only constitute suggestions to idle programmers. If someone is willing to implement it - good! If not, well, there's nothing to do about that.

Any takers?
I would gladly contribute on the part of user and designer, but
not sure how much coding I would want to dom I could at best develop pseudocode for the framework..

The guy at the top of this webpage, Jon Farmer, on the OMG site, I worked with for a week http://www.omg.org/memberservices/testimonials.htm

And he said the typical development process they have is they have like 4-5 coders, he said one of their developers will think up the for the code,
pass it off to one developer that will go through and define the structure
and start on the code, but he gets bored of the coding and will
usually move onto something else.. But their other coders will gladly finish the coding process up.. This is my experience with coding projects I've left behind is that I usually leave enough comments and ideas in
my code that those coming after me tend to have great ideas about how to continue the project, I mean the code I leave behind tends to make some people happy (for what reason I don't really know).. So I don't see myself as developing the technologies for blender, but helping out in the design process ultimately, the coding would bore me to tears as I've done so much it isn't even fun for me anymore.. But the design process is a lot of fun..

Blender is a fun program but its not fun to look at the source
or to try to figure out what is going on.. For some other people that's a
lot of fun.. Getting into the details of the implementation, that is..
But I've done it enough I can end up hacking forever and not getting anywhere.. That's why I prefer there be a design process in place, also
I think we need to document the code and establish some kind of
visual description of code dependencies.. At least to inform the
designers and at most to inform the coders.. I don't know what tools the
coders have available to them, but I know for Java its possible to
dump a Javadoc that creates a Webpage of the associated modules
in a java program, this would be nice to do with Blender, but unfortunately blender is in C and what dependency relationships
can you display other than function calls, includes and variable use?

For those wishing to writa code analysis tool that shows a
graphical dependency graph (maybe soemthing I should return to)
there is a module in Perl called RecDescent (stands for "Recursive Descent") which is a parser that cna be programmed with a
lexical language such as those used to write C-like compilers.
Anyhow, there is a library (from AT&T's research division, I think) that also works in Perl that can generate graphs from cartesian coordinate
pairs.. Like to get a circular graph of nodes you could do
(1,2), (2,3), (3,4), (4,5), (5,1) . A 2 tier tree structure might look like
(1,2), (1,3), (1,4), (2,5), (2,6) .

Having a visual representation of code dependencies also helps keep straight what changes where will affect what, so that we know what
are the sensitive and least sensitive parts of the codebase.. The more sensitive and fragile parts are the parts that will need to be refactored,
because anything will make them break and bugs will keep popping up..
I imagine it will be like pushing a Hernia in and watching something heniate somewhere else in the code.. This is most cetrainly the experience of the blender coders..

But I'm speculating, but I think my speculations are relatively accurate considering the purportion of cussing to comments in the source code
of blender when it was originally released..
Last edited by thorax on Tue Jun 10, 2003 4:31 pm, edited 1 time in total.

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax » Tue Jun 10, 2003 4:17 pm

NateTG wrote:

If we have sufficient manpower, I think it will be very beneficial to the blender community. Especially if we can get coder cooperation.

The way I see it our course of action would be to:
1) Announce on Elysiun chat, and see what support we get
2) If support is sufficient, (I would say a team of at least 9 would be needed if we want to prepare a cohesive feature list) request a special forum on Elysiun
3) See where it takes us.
Well I would be all for weeding out feature requests.. I think there will need to be a way to categorize the feature requests.. I guess that;s what you were saying, its not good to put the feature requests into a message base because they can get shoved to the bottom.. Its best that
they be in some kind of folder categorization.. But I imagine doing the
categorization first to get a feel for the classification then when its
pretty much obvious no features will delve out of the normal set, we
can make it into a classification system for future requests,
the users can then also find feature requests similar to theirs, either come up with better ideas and suggest them or decide that another
feature request for the same thing would be redundant and
to maybe vote on the feature..

I think I could help out in the development of a categorization system
in PHP if someone else can deal with the MYSQL stuff.. I could develop a
object structure to interface with database calls and such..

So my ideas for the shape of the categorization system for feature
requests (Assuming we are successful with Elysiun)
would be to Design Categorization system for feature
requests, maybe some way to sub-classify features, then
a voting method to allow users to vote on feature requests (using their email address or their username) to help prevent multiple non-unique votes for a feature request.. It might be the case the person must
enter is a unique answer when voting, maybe a descriptive justification
for the redundancy in the request..

Then we could offer up a search engine for the developers that allows
them to search the database by category, number of votes,
in the case that my UMark is used (which I will gladly open source)
the developers will be able to do search by related interface
element.. Like if someone was suggesting a feature in the IPO editor,
they might use UMark to associate with their feature request and
store the image depicting the interface and the x,y coordinates with
that feature.. We then only have to search the database by imagename plus x,y.. The idea is to give the coders more quick analytical ways to peruse the database beyond simple word search which will only
find matches where the users used the correct terminology (or at
least the terminology according to the developer).

Its possible that the coders could even include links like those
in UMark to associate pieces of code in blender with features in
the interface, so that anyone modifying the source will know what the source is affecting in the interface.. Also opposite would prove useful
of interface to code relationships just by query the codebase for modules
that contain links to UMark (or a similar application).. The code could then be categorized by association to the interface..

UMark is nto flexible enough for this, but I believe the idea is valuable to
making it easier for users to make feature requests, query the database for tutorials and suggestions.. A user-driven documentation
system like what is on www.php.net is what I'm proposing,
but instead of using a keyword search, the users could query the database by pointing at images.. All I have to do is get UMark to
generate the code to query a database using XY coordinates instead of keyword search, and its not hard to do..

dreamerv3
Posts: 119
Joined: Wed Oct 16, 2002 10:30 am

Post by dreamerv3 » Tue Jun 10, 2003 9:49 pm

broken wrote: Like ton said, the best results can come when everyone works together when people listen to each others' viewpoints and try to understand why they think differently.
Exactly, I'm certainly willing tolisten to other people viewpoints.
broken wrote: Rushing off and diving into code without understanding what Blender's users even want and what their philosophies are would be dangerous.
It would risk fragmenting the community, and in the OpenSopurce world thats a very dangerous thing, you want a united strong community of users and coders, you don't want loosely knit tribes of people agreeing sometimes and fighting other times...

I for one would be happy to learn a programming langauge if I knew the app I wanted to develop for was written in that langauge, and I did my research before choosing C++, show me 5 applications written in another language, 5 apps written in some langauge that !(c/c++), Is not c/c++.

And most of the 3D apps in c/c++ land are more C++ than C.

Why not just join the fUBo (functionality board) tha Ton suggested.

We should ideallybase it here since the coders read the stuff here more often and if you want to communicate to them choose the location of highest coder frequency.

Ton?

How were you thinking of implementing the Fubo here?

Polling should be integral to it, since that provides instant feedback to readers of the community will.

Jamesk
Posts: 239
Joined: Mon Oct 14, 2002 8:15 am
Location: Sweden

Post by Jamesk » Tue Jun 10, 2003 11:57 pm

Ton:: Thank you for offering a designated forum or mailing list here. We could perhaps get back to that after polling the strict users about what way to go with this.

Otherwise, the last few posts have really indicated how important it is to keep coders and users separated at the baselevel of feedback, so to speak. I mean absolutely no offense by this, and I'm not trying to be rude in any way, BUT the enourmous gap between coders' and artists' minds is evidently not to be taken lightly. The previous 3 - 4 posts would definitely scare most "ordinary" users away. Far away. :D

So, I'll try gently to get back to my point here::

A---Let us assume that we introduce a forum here or at Elysiun. That forum is strictly for users/artist. We will make sure that the forum is used for very organised, well thought-out feature requests. All participants help out in the making of highly specified "white papers" describing the requests, one by one, in as much detail as possible, from a user point of view. A few selected coders (preferably with a strong connection to the artist community) provide feedback as these specifications are refined as well as weed out any obvious insanities. Aside from those particular tasks, the coders have no say in the matter. This means that the BUIG-forum would have a small administrative unit composed of a number of people from the user community, plus one or two coders.

B---The documents resulting from A above are then passed on to the Functionality Board for further revision. At this point, the requests are now the "property" of the coders' community. That would mean that the users are no longer supposed to participate in further adventures of that particular request, unless those persons making the actual implementation ask for more feedback. This assumes that the request in fact is considered a worthwhile feature by the FuBo, and that it in fact gets implemented

C---From this point on, everything else works just as before. The BUIG would simply provide feature requests - but those requests will be far better organised, refined and complete than the requests made by individuals using the tracker. The request-tracker would of course continue to work as usual. So the material originating from the BUIG would simply constitute an additional source of request-type feedback - but with a special "seal of quality"...

What do you all say? Should we go ahead polling the users? Or what? :D

Post Reply