![]() ![]() ![]() ![]() How are Mac/Win improvements to be handled in the future? Don’t like this WinRhino users? Use WinRhino. Seems possible (and possibly prudent?) in the long run, but in the short run, MacRhino will be better received by new Mac users if it is a super well-refined Mac-like product. Will MacRhino/WinRhino working methods be 100% similar? It’s hard enough for one person to do a high-quality rendering on one machine, let a lone two different ones with different operating systems. Yes for geometry (as is currently the case), but I believe this is not essential in the near future for materials for rendering. Will MacRhino/WinRhino files be 100% interchangeable? Here are a few questions that seem worth answering clearly and obviously: Whether McNeel is in fact still identifying these goals or simply needs to more clearly communicate them in an obvious manner is unclear. If you haven’t, immediately seek out a test ride!)įrom my perspective, a primary problem is that there (still) seems to be some ambiguity among users about McNeel’s goals for MacRhino specifically, as well as a future where WinRhino and MacRhino will soon both be in the wild together. [If you’ve ever driven one of those new Corvettes on twisty back roads (as a friend of mine foolishly let me do with his new car a few weeks ago), you know exactly what I mean. Emotionally, most people will fall deeply, passionately in love with “Type B” if it fits like a glove or gives them cheek-splitting grins, even if it’s a bit tempestuous or impractical. Software users, like car owners, may intellectually and analytically convince themselves of the benefits of “Type A” because it’s sensible and capable, despite being a bit homely or clumsy. Absent larger, clearly communicated and agreed upon goals from McNeel, the end result is often “misunderstanding”, and/or “why fix what ain’t broke?”ĭespite appearances, “Type B” items are incredibly important to the ultimate success of products-especially ones that people spend a good deal of time with. Usability items are MUCH more difficult to evaluate and implement because different users may value very different (and often contradictory) ideas thus, agreement on “the problem” is often rare, and improvements are almost impossible. This topic is my primary concern at this juncture. “Type B” items are Qualitative/Emotional/Delight issues occasionally raised by the naive or stubborn. If functioning properly -> Instruct user about their error. If Not functioning properly -> Validate problem and fix. They’re generally pretty easy to evaluate and implement since they are usually Yes or No items. “Type A” items are Quantitative/Analytical/Performance issues, comprising the majority of comments here. Further, there is no clear way of distinguishing between A or B other than through wordsmithing. This is a huge problem if you’re posting about B. Generally, people assume that ALL posts are about A. Part of the challenge on the forum is that there are (other than “how to” questions) at least two different types of posts: This makes for some good entertainment at times, but rarely seems to advance meaningful change (with the exception possibly being the very bold move a new light bulb icon in the layers-Wheee!). Neat idea, but this won’t work for “all” scenarios.” (Ignoring the possibility that ignoring 5% of “all possible scenarios” might help dramatically improve 95% of all other scenarios.) Here’s a bit of code that might get you there if you’re looking for a workaround.” Narcissistic Nat: “Who would ever want to do that? I don’t.”.Chicken Little: “MacRhino and WinRhino absolutely, positively, have to be completely identical because reasons!”.With responder missing the point that “the lengthy list” IS the point). Helpful Horatio: “Oh, that’s not how you do that.Over the years, usability suggestions are continually subjected to a predictable gauntlet of interrogation (by both commenters and McNeel folks, alike). The forum does many things very well, but is it good for usability items? Hmmmm… not so sure. I’ve got some pent up energy on this topic, so please forgive the length of this. Pascal: Your suggestion to “complain loudly about clunky workflows”, is something I don’t hear nearly enough! ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |