Talk:Cobalt (CAD program): Difference between revisions
→Bulleted list and the same list again?: new section |
→Bulleted list and the same list again?: specify section |
||
Line 255: | Line 255: | ||
== Bulleted list and the same list again? == |
== Bulleted list and the same list again? == |
||
Not sure why we needed the same list twice so I merged that section together. Probably |
Not sure why we needed the same list twice so I merged that ''Tool sets'' section together. Probably needs more work to look right. I also removed some rather OWNery hidden comments that seemed to be suggesting that only a select few can edit the page. Perhaps I misunderstood those comments? --[[User:Jubileeclipman|Jubilee]][[WP:CTM|♫]][[User talk:Jubileeclipman|<font color="darkorange">clipman</font>]] 01:48, 1 July 2010 (UTC) |
Revision as of 01:50, 1 July 2010
This is the talk page for discussing improvements to the Cobalt (CAD program) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | Links from this article with broken #section links : You can remove this template after fixing the problems | FAQ | Report a problem |
Sources affiliated with the subject
wjemather: You slapped a tag marked “Primary sources or sources affiliated with the subject are generally not sufficient for a Wikipedia article.” Luc Heiligenstein published a comparative review of Cobalt and is not associated with the subject. I googled reviews, found his name, contacted him, and he responded. Does it surprise you that an author of a review of a CAD program actually knows what he is talking about and uses the program?
I did the same on Kilogram: I contacted the Ph.D. researcher working on the watt balance and exchanged some sixty e-mails with him. The fact that a Wikipedian would contact an expert might come as a shock to you and others since it is so common for Wikipedians to just regurgitate what they read from Popular Mechanics. I’d quote still other authors if I could find them. Unfortunately, there are few published reviews of Cobalt, so you go with what you have.
In the mean time, I suggest you do something more constructive to do with your time than start an AfD with the intention of deleting content.
My intentions could not possibly have been clearer that I didn’t want that to be a forum for just me to display my work because right at the top of the page, it began with this:
“ | “Topical and germane” additions to this gallery are welcome; that is, additions should be of interest to readers interested in Cobalt’s solid-modeling and image-rendering capabilities. Please keep attributions succinct and take care to avoid commercialism. | ” |
It would be just splendid if others did precisely as invited and diluted out my contributions at the gallery. Moreover, I invited Luc to provide me with some solid models he created using Cobalt so readers could see more complex work. In spite of the drop-dead-obvious intentions as evidenced by the invitation on the gallery, you offered up this doozy at your AfD: “This appears to be nothing more than a forum for advertising the authors work and/or capabilities of a particular CAD package.” I find that to be exceedingly offensive and a violation of “assume good faith” (or a profound case of jump to conclusions instead of actually read what’s there).
I didn’t have you jumping all over my bones when I slaved over Thermodynamic temperature and Kilogram. Apparently because one can’t go buy either. I think you are a tad too sensitive over the fact that Cobalt is a product for sale and therefore leapt to conclusions and assumed all sorts of nefarious motives where none existed. I use the program and believe in it. If you think the article needs to be balanced with an equal amount of verbiage devoted to the program’s shortcomings, why don’t you become an expert on the subject and add to the article rather than make life difficult for those who fully understand it?
It would also be exceedingly good form if you’d bother to start even the most minimal of a discussion thread here on this page and explain what’s on your mind (and afford me an opportunity to explain myself) rather than run about with your tags. Greg L (talk) 00:04, 11 March 2010 (UTC)
- P.S. BTW, I did the same thing over at Thermodynamic temperature: I contacted Dr. Daniel C. Cole, who published several landmark papers on the goings-on at absolute zero and we exchanged dozens of e-mails. He helped me write some of the article (ghost-author-style). He’s cited in the first reference. It sure beats arguing with Wikipedians who fancy themselves as experts on the subject because they took a whole quarter of thermodynamics in college.
If you think there is too much “Gosh-golly-gee” tone in the article, then point it out please. As far as I can tell, the article explains that Cobalt has an easy learning curve (which anyone who knows anything about the program knows is ultra-true) and it explains pure, cited facts regarding its features and how the program works. Greg L (talk) 00:48, 11 March 2010 (UTC)
- This article seems fine to me; I don't know how else a pretty comprehensive technical description could be given. Tony (talk) 01:00, 11 March 2010 (UTC)
- How is it that an author of a review in an independent publication is considered a primary source, or source affiliated with the subject? Bizarre. Also, what in the article is not verifiable information, wjemather? Nowhere does the article speak of the benefits of Cobalt over any other CAD program. I found my way to Cobalt and was pleased to see the progress of this budding article. I am a frequent user of a variety of CAD/CAM packages. I often find on Wikipedia that articles for certain CAD/CAM programs sound close to the sales pamphlets I get for said companies at the office. This article is nothing but good, tight writing. Give it a rest. SteveB67 (talk) 05:12, 11 March 2010 (UTC)
- Agree w/SteveB67.--Epeefleche (talk) 07:20, 11 March 2010 (UTC)
- How is it that an author of a review in an independent publication is considered a primary source, or source affiliated with the subject? Bizarre. Also, what in the article is not verifiable information, wjemather? Nowhere does the article speak of the benefits of Cobalt over any other CAD program. I found my way to Cobalt and was pleased to see the progress of this budding article. I am a frequent user of a variety of CAD/CAM packages. I often find on Wikipedia that articles for certain CAD/CAM programs sound close to the sales pamphlets I get for said companies at the office. This article is nothing but good, tight writing. Give it a rest. SteveB67 (talk) 05:12, 11 March 2010 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Multiple issues
- First off there is nothing in the lead to indicate why this is even notable, although I tend to think it probably is. 3rd party sources should support more than just 2 sentences of this article and at least establish notability, and a single blog published opinion piece just doesn't cut it. It matters little if everyone on the planet think that it is the easiest to use piece of software ever written if it cannot be well supported by proper references. Words such as importantly and notably should have no place in the article. The Drafting Assistant and Animation tools sections seem to be either a marketing presentation or an instruction manual – either way, not what you would expect to find in an encyclopaedia. As with the now deleted gallery article (I assume you now withdraw your inappropriate remarks above with regards to this) the collection of images add little if anything without explaining their significance to the subject and I'm sure many are entirely unnecessary. wjematherbigissue 18:19, 11 March 2010 (UTC)
- Quoting you: First off there is nothing in the lead to indicate why this is even notable. Oh, and now you are questioning whether the article is notable, which implies you think the article ought to now be nominated for deletion. I don’t appreciate your style, wjemather. First you complain that the article wasn’t sufficiently cited. Faced with a clear consensus that it is, you bizarrely strike back and attempt to buttress your basis for your first move by entirely changing the subject to one of “notability.” Do tell, what part of this lead (from another high-end CAD program called Pro/ENGINEER) strikes you as notable?
Pro/ENGINEER is a parametric, integrated 3D CAD/CAM/CAE solution created by Parametric Technology Corporation (PTC). It was the first to market with parametric, feature-based, associative solid modeling software on the market. The application runs on Microsoft Windows and Unix platforms, and provides solid modeling, assembly modelling and drafting, finite element analysis, and NC and tooling functionality for mechanical engineers.
- I tried to follow the convention used on other CAD packages and be double-sure to not make it read like this sales brochure (from SolidWorks):
SolidWorks is a 3D mechanical CAD (computer-aided design) program that runs on Microsoft Windows and was developed by Dassault Systèmes SolidWorks Corp., a subsidiary of Dassault Systèmes, S. A. (Vélizy, France). SolidWorks is currently used by over 3.4 million engineers and designers at more than 100,000 companies worldwide.
- Or, do tell, what about AutoCAD’s lead suddenly jumps out at you and makes you understand anything about the notability of major CAD packages?
- Or, for that matter, what about WriteNow, a word processing program that worked only on a Mac, is no longer made, and which sold for under $100 is “notable”?? If you’re going to start heading down this path, you have an ocean of work ahead of you. I suggest you study up on notability a bit more and stop trying to hit other editors on the head with your wild notions so you can exact some sort of ‘win’ here.
- You have your opinion and that’s fine. I think it’s time to leave this article to the CAD-editing specialists now. I’ve looked at your edit history and it seems you fancy yourself as some sort of orchestra leader who runs about making judgements about subjects you don’t understand. You know: approach other editors who have been doing all the heavy lifting on an article, tap your baton on their stand, mutter *tsk-tsk* and pronounce what you think of all its shortcomings. Now…
- I will no further entertain you by chasing your arguments and falling for your baiting as they flit around from issue to issue. You don’t exhibit sufficient knowledge of the subject of major CAD packages and “what is notable” and what is not to deserve any more than the right to land here and layout your opinion. Yet your writings come across as if you fancy yourself as having some sort of veto power of what other editors think. Greg L (talk) 19:00, 11 March 2010 (UTC)
- P.S. Now that you seem to have dreamed up a “notability” issue upon which to stake your claim, please go to Comparison of CAD editors for architecture, engineering and construction (AEC). There are sooooo many CAD articles on Wikipedia that apparently now need your attention for the betterment of Wikipedia. Thanks for all your help here. Much appreciated. Greg L (talk) 19:14, 11 March 2010 (UTC)
- To pick up on your examples. Pro/Eng "was the first to market...", "SolidWorks is currently used by over 3.4 million engineers...", "WriteNow was one of the two original word processor applications..." – they are statements that clearly indicate notability (the AutoCAD lead is actually quite poor). Incidentally, you raised the notability issue with your statement "there are few published reviews of Cobalt". I stated that I thought is was notable despite there being no assertion in the lead (or anywhere else in the article).
Since I have not disputed the accuracy of the content I fail to see how you could assume anything regarding my knowledge of the subject. I will also thank you not to advise upon what articles I may or may not contribute or raise concerns. If you would care to actually address all the issues, it would be much appreciated.wjematherbigissue 20:59, 11 March 2010 (UTC)
- To pick up on your examples. Pro/Eng "was the first to market...", "SolidWorks is currently used by over 3.4 million engineers...", "WriteNow was one of the two original word processor applications..." – they are statements that clearly indicate notability (the AutoCAD lead is actually quite poor). Incidentally, you raised the notability issue with your statement "there are few published reviews of Cobalt". I stated that I thought is was notable despite there being no assertion in the lead (or anywhere else in the article).
- Now you are just making a pest of yourself and are editing disruptively. How about all the other CAD programs that are on Wikipedia, as evidenced by the comparison chart? Or WriteNow? Or any number of thoroughly minor programs that have articles on Wikipedia? You purposely missed the point of my above links and aren’t making good-faith edits. Major CAD packages are notable because they are major CAD packages. You know that. You don’t need to act like a baby and slap the article with {I wanna be heard}-tags to discuss issues. Given that discussions are ongoing here, there is clearly no need for it. Given the fact that your earlier views were thoroughly trounced by consensus here, I have little doubt your new allegation of lack of notability will find an a disapproving audience here too; you might actually allow a small modicum of time for other editors to weigh in on your latest nonsense. Greg L (talk) 21:11, 11 March 2010 (UTC)
- We are not discussing the myriad of other articles with problems, we are discussing this one, and none of the issues I raised have been addressed. You have simply sidestepped and resorted to personal attacks and a bogus AN/I. I have made no allegation of lack of notability. I have stated that there is no assertion of notability in the article. That still stands, as does the original concern regarding inadequate citing that you mistakenly think has been resolved, along with all the other issues. wjematherbigissue 00:47, 12 March 2010 (UTC)
- I really don't see the citation issue. How densely arranged do you expect the ref tags to be in the main text? Tony (talk) 02:06, 12 March 2010 (UTC)
- Agree w/Tony.--Epeefleche (talk) 02:09, 12 March 2010 (UTC)
- Ummmmm.....Ok. WJE, This is some unique fantasy Wiki-world you seem to exist in. How on earth can you stand there and say that "none of the issues I raised have been addressed. You have simply sidestepped and resorted to personal attacks and a bogus AN/I". Probably not. You were clearly out-voted when it comes to the issue of independent referencing. You move on to say "It matters little if everyone on the planet think that it is the easiest to use piece of software ever written if it cannot be well supported by proper references". Hmmm. I'm curious what you consider a proper reference, since a review of the product by a neutral party in an independent reference doesn't cut it, in your humble opinion. It would appear that you are the one who needs to come to terms with the issues and quit the side-stepping. Consensus was clearly not in your favor. Deal with it.
As far as the lack of notability in the lead in: Stop. Not all of us need to see shiny objects, pomp and circumstance or flashy salesman in the lead in of the article to know it's notable. There are those of us who are content with solid, tight, technical writing. Move along, please. SteveB67 (talk) 04:36, 12 March 2010 (UTC)
- Ummmmm.....Ok. WJE, This is some unique fantasy Wiki-world you seem to exist in. How on earth can you stand there and say that "none of the issues I raised have been addressed. You have simply sidestepped and resorted to personal attacks and a bogus AN/I". Probably not. You were clearly out-voted when it comes to the issue of independent referencing. You move on to say "It matters little if everyone on the planet think that it is the easiest to use piece of software ever written if it cannot be well supported by proper references". Hmmm. I'm curious what you consider a proper reference, since a review of the product by a neutral party in an independent reference doesn't cut it, in your humble opinion. It would appear that you are the one who needs to come to terms with the issues and quit the side-stepping. Consensus was clearly not in your favor. Deal with it.
- Wjemather, the issue of citations was settled yesterday when four of the five editors weighing in on this page opined that the article is sufficiently and properly cited. You will not be allowed to drag this out like a case of herpes that just won’t go away just “ ‘cause I like ta.” End of story. Your continuing problem with the citations amounts to nothing more than Wikipedia:I just don't like it. The trouble (for you) is that Wikipedia is ruled by consensus and doesn’t take kindly to editors who edit disruptively by slapping {I DISAGREE}, {DISCUSS, DISCUSS} and {HAH! EAT THIS!}-tags on articles whenever they don’t get their way.
After not getting your way on the “citation” issue, you then do a shot across the bow with the issue of “notability”, which is totally absurd. I don’t buy your playing coy when you write I have made no allegation of lack of notability. I have stated that there is no assertion of notability in the article. Your meaning was clear enough.
As for your allegation that the ANI against you was “bogus,” if you keep up with your editing against consensus or disruptively editing to make a point, you’ll find yourself the subject of yet another one. That’s not a threat, it’s a pledge. It’s time to start paying attention to cause & effect.
Now we will put the “notability” issue to bed:
- Obviously Notable. Given the number of CAD programs that have articles on Wikipedia, as evidenced by Comparison of CAD editors for architecture, engineering and construction (AEC), and given the hundreds—if not thousands—of obscure programs, like those for Linux, that hardly anyone in the real world has even heard of) that have articles here on Wikipedia, it’s obvious that a major parametric-based CAD program like Cobalt merits a Wikipedia article. Greg L (talk) 04:16, 12 March 2010 (UTC)
- Notable. Clearly notable as it is a big player in the CAD game. SteveB67 (talk) 04:56, 12 March 2010 (UTC)
- Notable. Per SteveB67.--Epeefleche (talk) 05:53, 12 March 2010 (UTC)
- Notable. Perhaps originally it was reasonable to mention notability; but the external links and other recent additions put the matter beyond doubt, I think. I expect critiques (negative) will be added soon enough in the main text, too. We now have a valuable WP article, I believe. Tony (talk) 06:34, 12 March 2010 (UTC)
Consensus has still not been reached on all of the issues I raise because they have simply not been discussed.
- No assertion of notability in the lead. A simple statement saying it is one of the leading high-end CAD packages would suffice as long as it can be cited.
- Lack of reliable 3rd party references – this issue is starting to be alleviated with the addition of two further external links, although it would be good if these could be converted to inline citations and there were more of them.
- Use of inappropriate words such as importantly, easy, and notably.
- Marketing presentation/instruction guide sections
- Gallery full of images with no apparent purpose other than decoration
I appreciate Tony's acknowledgement that my concerns are/were valid and I hope having them listed for clarity might help focus this discussion. wjematherbigissue 07:41, 12 March 2010 (UTC)
- I don't think its obligatory or indeed necessary to have an overt assertion of notability ("It is notable because...."). In this case, as can be gleamed from the excellent and comprehensive Al Dean review, it seems that its notability stems from several factors, least of all because there are precious few CAD programs written from Mac and PC, and that it is intuitive and easy to use. I believe such facts, already well laid out in the lead, will stand out to any user of CAD software as making the product noteworthy. I also think that the image gallery serve a purpose other than simple "decoration" as it demonstrates the product's quality and versatility. I'm no expert, but the range of subject matter and rendering quality are also likely to be qualities that mark out the product from its competition. Ohconfucius ¡digame! 09:36, 12 March 2010 (UTC)
- Quoting you, Wjemather: I appreciate Tony's acknowledgement that my concerns are/were valid and I hope having them listed for clarity might help focus this discussion. I see, well… four of the five editors on this page opined that the article was sufficiently and properly cited to an independent reliable source. The lone holdout was you. Since then, I added another citation and Ohconfucious added some external links.
Seeing that every single other editor didn’t agree with you, you then raised a new issue: how there wasn’t anything in the lead to indicate notability. And again, 80% of the editors on this page don’t share your concern there, either.
You further wrote That [the issue of notability] still stands, as does the original concern regarding inadequate citing that you mistakenly think has been resolved, along with all the other issues. That suggests to me that you don’t believe the consensus view prevails on Wikipedia and that if there is a holdout who wants to jump up and down and persist at arguing, everyone else here—who have other things they had hoped to do on Wikipedia to keep it a fun hobby—has to (*sigh*) and keep on debating with you until the heat death of the universe.
So where this leaves us is A) The consensus view is that this article is properly cited and is clearly notable, and B) you still aren’t personally convinced of these things, exhibit a keen interest to keep discussing every bit of what you disagree with, and believe that obligates everyone else to keep discussing things with you and make you all happy as a clam here. Do I have the current state of affairs accurately summed up? If we fail to keep coming here to discuss things with you, does that mean you will seemingly take on an attitude of “all the others are all wrong” and slap {DISCUSS–I DON'T LIKE IT}-tags on the article to force people to keep discussing things with you? Or are you beyond that now?
So let me cut to the chase: The consensus view if that this article is notable and properly cited to independent reliable sources. Are you going to accept and abide by the consensus view? Yes or no? Are you going to raise new issues? Yes or no? If the answer to the first question is “no” or you answer “yes” to the second question, please bone up on WP:Consensus; it lays the foundation for all that prevents chaos and edit warring from running rampant on Wikipedia. I would also suggest you take a look at Wikipedia:Drop the stick and back slowly away from the horse carcass.
I have about 40 hours devoted to creating this article, which includes the time making those fine animations that very effectively communicate something that would be difficult to convey with words. I am so disappointed that the sum of my labors has failed to impress Wjemather. Your contribution to the article—the 20 seconds it took for you to slap tags on the article to signal that the article doesn’t meet with your approval—has certainly started a great deal of discussion here. Greg L (talk) 16:05, 12 March 2010 (UTC)
- Well, your 40 minute rants have done nothing to help the discussion, especially when you constantly don't read, misread and/or misrepresent others contributions and seek to undermine other editors. It has only served to make this an unpleasant experience for all involved, and no doubt been successful in dissuading other editors from having their say. Anyhow, the two most pressing issues have at least begun to be addressed, especially thanks to the helpful contributions from Ohconfucius. I still feel there could be a clearer indication of notability in the lead and more good references, but I'm sure that will evolve. wjematherbigissue 17:53, 12 March 2010 (UTC)
- I won’t be baited by your characterizing another’s posts as 40-minute-long “rants.” I explicitly asked whether you will conform to Wikipedia’s requirement that editors abide by the consensus view and not edit against consensus. You refused to pledge to do so and exhibit only keen interest in further engaging in protracted debate on issues the rest of us consider to be satisfactorily addressed. I don’t know of anyone here who is interested in further entertaining you with your wikidrama, but I have no stomach for it.
The consensus here is that the article is clearly notable and sufficiently cited. If you persist to disrupt Wikipedia by slapping your {Discuss-DISPUTE-I DON'T LIKE IT}-tags on an article to force debate in defiance of consensus, you will be held accountable. I understand you might not agree with the consensus here that the article is sufficiently cited and is notable; in the military, that’s called “So sad–too bad.” You will have to live with that and move on. Goodbye and happy editing. Greg L (talk) 21:57, 12 March 2010 (UTC)
- I won’t be baited by your characterizing another’s posts as 40-minute-long “rants.” I explicitly asked whether you will conform to Wikipedia’s requirement that editors abide by the consensus view and not edit against consensus. You refused to pledge to do so and exhibit only keen interest in further engaging in protracted debate on issues the rest of us consider to be satisfactorily addressed. I don’t know of anyone here who is interested in further entertaining you with your wikidrama, but I have no stomach for it.
WP:FIXIT
Well guys, please remember that this is not a FAC or GAN (yet), so the standards are more relaxed, and we should treat this accordingly. It's useful to have input on how the article can be improved, but the terrible bickering of this fashion is clearly not helpful one iota. If someone still does not feel the article sufficiently asserts notability, we should ask an admin whether a {{db-nn}} would be entertained - I'm pretty sure it will not. If it is accepted that this article's subject is notable, which seems to be the case, then it would be a case of roll your sleeves up and WP:FIXTHEPROBLEM. Thank you for your attention. Ohconfucius ¡digame! 02:01, 13 March 2010 (UTC)
- Agree w/Oh. Clearly notable. Also clearly viewed as such by consensus of opinion. Time I would hope to respect consensus and end the fillibuster, or as Oh indicates to take it elsewhere (where I agree w/his prediction, but of course I could be wrong). Continued refusal to respect consensus is now disruptively wasting everyones' time here.--Epeefleche (talk) 02:11, 13 March 2010 (UTC)
- The article was less than 70 hours old when progress towards expanding and improving it ground to a halt. I’d like to roll up my sleeves and concentrate on content, myself. Greg L (talk) 03:02, 13 March 2010 (UTC)
Here are two references that show Ashlar Vellum's history with CAD.
- Borzo, Jeanette (November 11, 1991). "Ashlar adds 3-D to its computer-aided design". InfoWorld. 13 (45): p. 16. ISSN 0199-6649.
{{cite journal}}
:|pages=
has extra text (help)
- Milburn, Ken (April 30, 1990). "Ashlar Vellum Gives Intuitive Interface to Macintosh CAD". InfoWorld. 12 (18): p. 73–77. ISSN 0199-6649.
{{cite journal}}
:|pages=
has extra text (help)
SWTPC6800 (talk) 04:21, 13 March 2010 (UTC)
- Wow. You are so damned good at digging stuff up! This is a real blast from the past. As you know, these aren’t reviews of Cobalt, but of Ashlar’s flagship product, Vellum. The 1990 article is a review that touches quite a bit upon its easy-to-use interface. The 1991 article tells of when Vellum went to 3D wireframe. That is the exact version of the program I first used. Now that I have an Intel-based Mac, I wouldn’t normally be able to use that old program (though I could use Graphite, which is its successor). However, I installed an emulator known as Sheepshaver that allows me to run my entire old Mac Classic OS (7.5.5), including Vellum (*wistful sigh…*). I doubt either of these are sufficiently relevant to this Cobalt article given their age and the huge gulf between then and now as far as product features. However, I’m going to take these two links and add them to the Ashlar-Vellum article, which needs a boat-load of work. Thanks again. Greg L (talk) 04:49, 13 March 2010 (UTC)
P.S. …except there’s this mind-reader called Ohconfucius, who keeps on doing the exact same edits the exact same way I would was planning on doing them. Thanks. Greg L (talk) 04:54, 13 March 2010 (UTC)
All: I thought any of you trying to dig up head-to-head reviews comparing CAD packages, might be wondering “why is there such a paucity?” You’re not alone. I thought you’d be interested in Kevin Quigley’s post here at WorldCAD Access, “What Happened to Head to Head Reviews?” The guy uses SolidWorks, Cobalt, and VX, which isn’t listed on Wikipedia’s CAD comparison list. Greg L (talk) 21:21, 15 March 2010 (UTC)
Seealso section
I removed a few links, per WP:SEEALSO, already found in the lead. --Tom (talk) 19:45, 14 March 2010 (UTC)
- the links were 3D computer graphics, 3D modeling, and Ray tracing (graphics)--Tom (talk) 19:48, 14 March 2010 (UTC)
- Yeah, saw that. Thanks. I appreciate all the help I can get here, Tom. There is no bright-line rule about repeating links in See also sections; the governing guideline says links are “generally not repeated” if they already appear in the body text. But as the guideline also says, “whether a link belongs in the "See also" section is ultimately a matter of editorial judgment and common sense.” This particular subject (Cobalt) falls under the broad umbrella of 3D graphics, solid modeling, and CAD. And under this umbrella, Wikipedia has some overlapping articles that really could use some consolidating; there is 3D computer graphics, which is distinct from 3D modeling, and both of which—as you noted—are mentioned and linked in the body text.
Unlike an article on, say, Sacramento, California, we don’t need to repeat a link in the See also section for distinct and easy-to-recognize things like Sacramento County when it’s already in the body text.
But in this particular case, where the subject matter is more obscure, the terminology arcane, and where there is a nearly annoying level of overlap in Wikipedia’s related articles (both in content and in the article names), I thought it more convenient for the reader to have a comprehensive list of related articles so the reader doesn’t have to study and parse the body text to discern the fine distinctions between the links. Wikipedia’s practice of aliasing links beyond all comprehension until they effectively become Easter Egg hunts tends to increase the value having comprehensive and complete See also sections, in my opinion. Moreover, Wikipedia has more articles than you can shake a stick at where the same paragraph has multiple links, aliased different ways, but which all point to the same target article; you can’t tell my looking at them and because of redirects, you have to click on the S.O.B.s to find out where you are actually taken to. In short; body text links in many cases aren’t as definitive and precise as on might hope; it depends—in part—on the subject matter. So…
It’s a judgement call, but as I wrote in my edit summary when I restored the links, “Repeating links in ‘See also’ sections is permissible and desirable [in this case] because many readers don’t want to wade through the body text to find every related article. You know: convenience for the reader.” Greg L (talk) 03:36, 15 March 2010 (UTC)
- Sounds like a reasonable exercise of good judgment. I've actually struggled with the same guideline myself elsewhere, and appreciate the analysis.--Epeefleche (talk) 04:49, 15 March 2010 (UTC)
- The links are covered in the lead, not the main body, so nobody needs to "wade" or even scroll down. If the desire is for this article to reach FA status, these links should be removed. --Tom (talk) 13:45, 15 March 2010 (UTC)
- Yeah, saw that. Thanks. I appreciate all the help I can get here, Tom. There is no bright-line rule about repeating links in See also sections; the governing guideline says links are “generally not repeated” if they already appear in the body text. But as the guideline also says, “whether a link belongs in the "See also" section is ultimately a matter of editorial judgment and common sense.” This particular subject (Cobalt) falls under the broad umbrella of 3D graphics, solid modeling, and CAD. And under this umbrella, Wikipedia has some overlapping articles that really could use some consolidating; there is 3D computer graphics, which is distinct from 3D modeling, and both of which—as you noted—are mentioned and linked in the body text.
- Well, I am darned pleased to hear that you fancy the notion that this article might have FA-potential, Tom. I don’t perceive a rigid adherence to common practices best serves readers in this instance. Many of Wikipedia’s articles are lengthy and if we generally had most-every link that appeared in the lead text and body text being repeated in the See also section, the See also sections would be truly gigantic. But, because of the confusing similarity in article names that are being referenced in the lead text (3D computer graphics / 3D modeling / Solid modeling), and because of the present shortness of the article and extreme paucity of articles to which we can point readers, I think it more of a service to readers in this particular case to have a comprehensive See also section—there are only nine entries. This appears to be an instance where one man’s “editorial judgment and common sense” differs from another’s. Let’s see how others feel, Tom; this isn’t a fatal flaw (like “the article ain’t been writ with gooder grammar”) that requires immediate repair. Greg L (talk) 17:20, 15 March 2010 (UTC)
This is still a problem. The see also section's purpose is supposed to be to linkt he reader to other subjects which might be of interest to them; it is unlikely that a reader is going to plough the whole way through an article on a CAD program designed for photorealistic rendering without knowing what ray tracing is, especially as it is indeed linked in the article body. Chris Cunningham (not at work) - talk 15:22, 26 June 2010 (UTC)
Image gallery
According to Wikipedia:Image_use_policy#Image_galleries…
“ | …the use of galleries may be appropriate in Wikipedia articles where a collection of images can illustrate aspects of a subject that cannot be easily or adequately described by text or individual images. The images in the gallery collectively must have encyclopedic value and add to the reader's understanding of the subject. | ” |
It is not easy to describe the wide variety of images Cobalt can create. The gallery is therefore appropriate and the tag removed.
Note too that the gallery was discussed above at #Sources affiliated with the subject and the community consensus was clearly that the gallery was proper and encyclopedic and fully in compliance with our guidelines permitting them for just this sort of thing. Greg L (talk) 02:39, 26 June 2010 (UTC)
- But are eleven images really needed? Two different images of rendered watches? What aspects of the ssubject are being covered in the gallery which aren't covered in the article? I don't see that any of this was previously discussed. Chris Cunningham (not at work) - talk 15:25, 26 June 2010 (UTC)
- The gallery conveys the wide range of type of work Cobalt is capable of doing. It is exceedingly difficult to convey in words, the type of ray tracings and rendering capabilities and realism the program is capable of doing. One of the animations (the nozzle) is a real-time capture showing the surfacing as one changes the geometry and it shows the Drafting Assistant in action too. Yet another animation there is ray-traced rendering that even shows the refraction of glass. Eleven images saves 11,000 words. Greg L (talk) 18:40, 26 June 2010 (UTC)
- And the two different images of rendered watches? Chris Cunningham (not at work) - talk 12:23, 28 June 2010 (UTC)
- Now you’re just quibbling and are getting hung up on how the “subject matter” (watches) are the same. The one with the LCD display shows a different lighting effect.
You started out by slapping a tag on this article that spoke of “galleries of *random* images” when, in fact, the guideline is quite clear and says “However, the use of galleries may be appropriate in Wikipedia articles where a collection of images can illustrate aspects of a subject that cannot be easily or adequately described by text or individual images.” The gallery needs one more item to round it out with all rows filled. Then you remove control of thumbnail sizes and break an animation so it doesn’t even work. After I fix that, you opine that you prefer animations one has to click to make work vs. the self-running kind. Judging from your picture, you couldn’t possibly have decades of page-layout and technical writing experience. Yet here you are, starting out by wanting a gallery removed and and then quibble about an extra watch. Tell you what, go ahead and delete the watch with the LCD since you are apparently expert on CAD. I would be tempted to reciprocate and become an endless source of critique on an article you write except I see that you specialize in floating about, doing to other articles what you’ve done here.
Now, I will be exceedingly blunt here with you. This is not a personal attack. These are the facts as I see them. I agree with precious little with what you write here because it is obvious that you are citing policies (like our gallery and H:HTML guidelines) without understanding what they are really saying. It is also clear you don’t understand CAD. It is also clear you don’t understand page layout. So I am quite done debating you here since you have so much to learn. Please, just finish with the *improvements* you want to do so I can go back and fix the damage (like making animations once again function). I wanted to discuss legitimate concerns with you here but you are just being petty, quibbling over silly things. Greg L (talk) 17:06, 28 June 2010 (UTC)
- Now you’re just quibbling and are getting hung up on how the “subject matter” (watches) are the same. The one with the LCD display shows a different lighting effect.
- Rather, that would seem to be an ad hominem attack (ticking all the boxes: citing personal behaviour, alleging a lack of understanding of the subject matter, appealing to personal authority) aimed at silencing legitimate concerns about an article which is, at this point, almost under your exclusive stewardship. We've got a name for that. The talk page contains a record of the problems raised, and at some point you're going to have to actually answer them either to me or two whomever comes along next. So again, why are two images which illustrate largely the same capabilities of the subject both needed? There's already a Commons category for the subject and both images are in it. Without explaining why each image is included, it leaves it open to indefinite expansion, which isn't appropriate. Chris Cunningham (not at work) - talk 17:34, 28 June 2010 (UTC)
- Your objection over two things that are the same has already been answered. Your objection based on what might happen in the future (indefinite expansion) is absurd because that is a potential for all of Wikipedia’s galleries and that doesn’t stop us from using them. Your argument is shear nonsense. Greg L (talk) 17:40, 28 June 2010 (UTC)
- Rather, that would seem to be an ad hominem attack (ticking all the boxes: citing personal behaviour, alleging a lack of understanding of the subject matter, appealing to personal authority) aimed at silencing legitimate concerns about an article which is, at this point, almost under your exclusive stewardship. We've got a name for that. The talk page contains a record of the problems raised, and at some point you're going to have to actually answer them either to me or two whomever comes along next. So again, why are two images which illustrate largely the same capabilities of the subject both needed? There's already a Commons category for the subject and both images are in it. Without explaining why each image is included, it leaves it open to indefinite expansion, which isn't appropriate. Chris Cunningham (not at work) - talk 17:34, 28 June 2010 (UTC)
- Humour me by explaining why both of those images are needed, as I can't find the answer as previously supplied. Chris Cunningham (not at work) - talk 17:49, 28 June 2010 (UTC)
Third-party references
Matters of opinion in the article characterizing the type of uses most suitable for Cobalt are cited to reliable secondary sources not affiliated with the company. Those are MCADVision and MCADonline. Matters of fact, such as features lists, are cited to the company. Every effort has been made to find more second-party articles but the nature of CAD makes for slim pickings; that is simply the reality of what we have to work with. Besides, two citations is perfectly satisfactory to buttress the point that “The distinguishing characteristics of Cobalt are its ease of use and the quick learning curve for new users.”
Please also note that this issue of third-party sourcing was fully discussed above at #Sources affiliated with the subject and the clear consensus was that the article was properly cited. In fact, another editor jumped into the fray and later helped dig up more references. Greg L (talk) 02:46, 26 June 2010 (UTC)
- Leaving aside that it's nothing like a "clear consensus" and that half of the discussion consists of declaring other editors to be deliberately disrupting the article, that it came back up three months later is quite a strong indicator to me that the sources aren't sufficient. If there is a paucity of independent coverage of a subject then, as pointed out previously, the most likely interpretation is that the subject isn't that notable rather than that it is a unique exemption to our normal requirements for significant coverage in secondary sources. Right now, of the two secondary sources used, one isn't online or cited with sufficient clarity for readers to be able to find it for themselves and the other is a 404. To call that insufficient is an understatement. Chris Cunningham (not at work) - talk 15:07, 26 June 2010 (UTC)
- I really do my homework when writing articles. I call Ph.D.s who write peer-reviewed scientific papers when writing science-related articles, etc. I’ve exchanged 60 e-mails with the Ph.D. researcher working on the NIST’s watt balance while writing that article. For this article, I spoke many times with the owner of Ashlar. I’ve used their products since they first came out. No, the paucity of citations is not an indicator of “lack of notability” with this particular subject; it is a problem that originates form the complex nature of the programs (there are few people who are expert in many CAD programs) and the Internet age, which slaughtered the CAD-related print magazines. Greg L (talk) 18:08, 26 June 2010 (UTC)
- Well, that's an appeal to authority. It's not a rebuttal of the argument made (that the article presently lacks secondary sources). That's the point in the {{primary sources}} tag, which should be put back for the time being. Chris Cunningham (not at work) - talk 12:29, 28 June 2010 (UTC)
- The article doesn’t lack secondary sources. It cites two of them. I can e-mail you one of the articles if you like, or you can go to your library. Greg L (talk) 16:12, 28 June 2010 (UTC)
- The MCADonline source is a 404. The MCADVision source provides no date or publication information. The purpose of citing secondary sources is to allow for our readers to verify the contents of articles without having to do their own research, which is hardly satisfied by offering to email copies of them on the talk page. Chris Cunningham (not at work) - talk 17:26, 28 June 2010 (UTC)
- Oh, well, just pardon me all over the place. The two cited sources used to work. They are MCADonline and MCADVision and both are still on line. Have you considered going to those sources and trying to find links that aren’t broken??? Or do you just all happy as a clam by slapping tags on the article about how it “doesn’t have citations to independent sources” and calling that your “contribution for the day” to Wikipedia? Greg L (talk) 17:36, 28 June 2010 (UTC)
- If you have a problem with legitimate cleanup tags then feel free to go to WT:TC and propose that they be abolished. Don't take it out on people who come along and notice that the article's only secondary sources are either unavailable or inadequately cited and flag the article for cleanup on those grounds. The onus is supposed to be on editors adding material to ensure that sources are cited sufficiently to be verified, not on readers. Chris Cunningham (not at work) - talk 17:45, 28 June 2010 (UTC)
- I fixed one of the links (∆ here). They changed the “owner” of that Web site. The other ref will have to wait; I have real life (work) to attend to. Thanks so very much for your editing assistance so far in improving this article. Greg L (talk) 17:55, 28 June 2010 (UTC)
- When I'm reverted I refrain from editing until the matter is fully discussed. This prevents unnecessary edit warring. But I'm glad some good has come of this. Chris Cunningham (not at work) - talk 18:02, 28 June 2010 (UTC)
Section headings
With regard to this edit and the accompanying edit summary, which read “rather than relying on hacks to get a desired visual effect, just remove the headers, per WP:GTL#Headings and sections”, bolding text and making it big is not a “hack”; it is approved markup to make subsections more readable. Please don’t worry so much about how a particular visual effect is achieved. But thanks for trying, nevertheless. Accordingly, I went back to the method originally used, which is HTML for the subsection tags, which is 100% satisfactory according to Wikipedia guidelines at H:HTML, which states “however there are some situations in which the HTML alternative is useful” and specifically lists <h1> - <h6> as suitable code. Using the h-style HTML for the subsections (but not the sections) avoids what you refer to as “hack”, and it shows the subsections in the TOC (which is good), and it avoids the [edit] tags all crowded together one after another against the images (which is also good).
The one exception is the Animation tools sub-section. It is long enough that it would be helpful to be separately editable. Accordingly, I used the ==== type wikimarkup for that one. Greg L (talk) 03:47, 26 June 2010 (UTC)
- Firstly, from a purely technical point of view you need to use H3s and not H4s so that header levels are consecutive, per WP:HEADER. Secondly, I don't actually see any rebuttal there to the main point raised, which was that sections as little as fifteen words long do not need their own headers. It's worth pointing out (I could make this pretty broadly with regards to the current control problems on this article) that having a good argument for doing something is only the first part of the process of consensus by which articles are maintained here; it is also a requirement that others agree with said arguments. Chris Cunningham (not at work) - talk 15:02, 26 June 2010 (UTC)
The big bold level-three hierarchy
- Well, as for “consecutive” headers, where I skipped from two to four, that’s because there are only two levels of hierarchy being used here and that gives us some flexibility. WP:HEADER isn’t addressing a nuance like this; it is just stating the obvious (level one, level two, level three). Wikipedia’s third-level header looks awkwardly more pronounced than the second-level header so I don’t use it if I don’t have to—which is pretty much never since I haven’t yet had such a complex article that four or five levels of hierarchy were required.
So I skip down from level two to level four
- I’m not the only one to do this. This is all about attractive page layout that makes it easy for the eye to intuitively parse structure and find relevant text—one shouldn’t worry so much about the behind-the-scenes coding details that make that happen. You strike me as a “programmer type”. I mean that in a nice way. Greg L (talk) 18:31, 26 June 2010 (UTC)
Well, no. The W3C quite specifically says:
Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example.
Having an "attractive page layout" is strictly secondary here. That other people have done so elsewhere on Wikipedia is hardly an argument for perpetuating bad practice. You still haven't explained why paragraphs as little as fifteen words long need their own subsections, though I do see that yet again you've reverted another user who changed the headers back to wikitext. Chris Cunningham (not at work) - talk 12:38, 28 June 2010 (UTC)
- Is there a firm guideline about this? I see nothing intrinsically wrong with skipping one level if the effect is good. It builds in a little flexibility for editors, doesn't it? Tony (talk) 13:07, 28 June 2010 (UTC)
- The W3C WCAG I linked to is the firm guideline. Headers fulfil a specific function in navigating HTML content. They are not simply a cute styling tool and should not be misused in such a way simply because an editor wants a certain weight or size of text somewhere on a page. Chris Cunningham (not at work) - talk 13:19, 28 June 2010 (UTC)
- Pardon me, but what status does that page have? If we left language and formatting up to programmers and developers, we'd be in a bad state. What exactly is the accessibility problem in skipping from H2 to H4? I don't see how there could be one. If this document is so important, why do WP's guidelines not tip their hat to it? Tony (talk) 13:53, 28 June 2010 (UTC)
- The W3C WCAG I linked to is the firm guideline. Headers fulfil a specific function in navigating HTML content. They are not simply a cute styling tool and should not be misused in such a way simply because an editor wants a certain weight or size of text somewhere on a page. Chris Cunningham (not at work) - talk 13:19, 28 June 2010 (UTC)
- That document is in fact linked to from WP:ACCESS for another reference, but it should be noted that WP:ACCESS repeats the given prescription anyway at WP:ACCESS#Headings. It probably should be referenced directly to the WCAG, but that's up to whoever is maintaining WP:ACCESS. Ultimately, practically everything we prescribe regarding article accessibility is drawn either directly from the W3C's documentation or from books which reference it. Chris Cunningham (not at work) - talk 14:23, 28 June 2010 (UTC)
- So what is the accessibility issue? I'm struggling to think of what it might be. Tony (talk) 15:08, 28 June 2010 (UTC)
- It's a fundamental part of the separation of content and presentation. By and large, exactly how wikitext is presented to our readers should not be an issue in how pages are composed; this prevents bugs when using different themes, or using a screen reader rather than a web browser or whatever. In this case, Greg is specifically using HTML to a) hack around the auto-generation of section headers and b) get a specific font size and weight. Both of these should be avoided if possible, and are imminently avoidable here. Chris Cunningham (not at work) - talk 15:25, 28 June 2010 (UTC)
- You’re making a tempest in a teapot. To keep it simple, we follow Wikipedia’s guidelines. Your mentioning W3C is just an appeal to authority. And notwithstanding their prescription to not skip a level, I’ll bet you can’t find a single real-life problem with screen readers and other themes. I’ve got a screenreader on my Mac. There is zero problem with WP:ACCESS. I find it instructive that when other editors have cited WP:ACCESS and screenreader issues as a basis for their pet this-or-that in the past at other articles, not a one was ever able to point to a real-life problem. It is just too easy to say “it causes problems for the blind orphans” and leave it at that.
Quoting you: Greg is specifically using HTML to a) hack around the auto-generation of section headers. Well, I just can not fathom why you would write such a thing. The applicable guideline, H:HTML, specifically allows its use. So your objection is without foundation. What HTML does is A) allow things to appear in the table of contents, and B) gets rid of [edit] tags in the body text. Sometimes these are desirable; just as H:HTML says.
Quoting you: You still haven't explained why paragraphs as little as fifteen words long need their own subsections. Now there’s a point I agree with. Well, because still other editors come in and do edits like this, and keep making them active editable subsections, complete with inclusion in the table of contents and all those packed-together [edit] tags crowded against the pictures. But I agree 100 percent with you; we don’t need editable subsections. However, to have attractive page layout and to make it easy to parse the page content, we wouldn’t want to fuse all that text into a run-on mess; the individual features need their own bolded rubrics. So I’m going to just go back to the
;<big>
method I used before. If the Tools section requires editing, it couldn’t possibly be easier to click on the [edit] link and edit that whole Tools section.♬♩ (*elevator music while I go make the change*) ♬♩
There. The result now looks much better than run-on mess you ended up with in your effort to avoid *verboten HTML*, which according to Wikipedia’s own guidelines, is perfectly fine for editors to use when the need arises. By using rubrics, it is exceedingly easy to see that select tools from the bullet list above are being fleshed out in greater detail. Greg L (talk) 16:05, 28 June 2010 (UTC)
- You’re making a tempest in a teapot. To keep it simple, we follow Wikipedia’s guidelines. Your mentioning W3C is just an appeal to authority. And notwithstanding their prescription to not skip a level, I’ll bet you can’t find a single real-life problem with screen readers and other themes. I’ve got a screenreader on my Mac. There is zero problem with WP:ACCESS. I find it instructive that when other editors have cited WP:ACCESS and screenreader issues as a basis for their pet this-or-that in the past at other articles, not a one was ever able to point to a real-life problem. It is just too easy to say “it causes problems for the blind orphans” and leave it at that.
- It's a fundamental part of the separation of content and presentation. By and large, exactly how wikitext is presented to our readers should not be an issue in how pages are composed; this prevents bugs when using different themes, or using a screen reader rather than a web browser or whatever. In this case, Greg is specifically using HTML to a) hack around the auto-generation of section headers and b) get a specific font size and weight. Both of these should be avoided if possible, and are imminently avoidable here. Chris Cunningham (not at work) - talk 15:25, 28 June 2010 (UTC)
- So what is the accessibility issue? I'm struggling to think of what it might be. Tony (talk) 15:08, 28 June 2010 (UTC)
- That document is in fact linked to from WP:ACCESS for another reference, but it should be noted that WP:ACCESS repeats the given prescription anyway at WP:ACCESS#Headings. It probably should be referenced directly to the WCAG, but that's up to whoever is maintaining WP:ACCESS. Ultimately, practically everything we prescribe regarding article accessibility is drawn either directly from the W3C's documentation or from books which reference it. Chris Cunningham (not at work) - talk 14:23, 28 June 2010 (UTC)
- I don't have a problem with using HTML where there's a genuine need to work around a limitation in wikimarkup. I dislike using it for presentational hacks where the sole argument is that the author wants a bit of prose to look a certain way. In the long run, you'll probably find that this is repeatedly changed back by well-meaning editors who don't see that said hack is necessary, which either means either littering the markup with passive-aggressive comments as previously or keeping this at the top of your watchlist indefinitely. As for the "appeal to authority", I pointed out that our guideline at WP:ACCESS says exactly what the W3C guideline says already. If there was an appeal to authority, it was only because I wasn't much interested in defending said document against someone picking it apart from first principles because he disagreed with it. Chris Cunningham (not at work) - talk 17:15, 28 June 2010 (UTC)
Unicode escape
This edit, which converted the template names {{nbhyph}} to the rendered non-breaking hyphen is sorta nice. But the trouble with doing that is other editors who come in later can’t tell that the hyphens are actually non-breaking ones. So if another editor comes along and types “3-D” from the keyboard, they have no idea that their treatment will behave any differently from the rest of the text; no one notices a problem that is already fixed transparently. To avoid this situation, I suggest we simply use the non-breaking hyphen template to produce the non-breaking hyphens so other editors can see that there is a nice little, behind-the-scenes nicety going on that avoids awkward word-wraps right in the middle of “3-D”. Seeing this will encourage them to copy and paste the non-breaking form. I mean, even I can’t tell just by looking at the rendered character whether I would be copying and pasting a non-breaking version of “3‑D” or not. But you can click on [edit] for this section, look at the code, and instantly tell whether you can safely copy and paste that last “3-D” or not. Greg L (talk) 03:23, 26 June 2010 (UTC)
- I'm stepping into territory which I find deeply unpleasant here, but the MoS says nothing about the use of non-breaking hyphens. Why are they deployed here in the first place? Was this discussed? It's certainly the first time I've seen anyone go to that length for "3-D" (which is very rarely going to be split at the hyphen anyway). If it's to be retained, wouldn't it be better moving the whole word to {{3-D}} and transcluding that each time? Chris Cunningham (not at work) - talk 15:17, 26 June 2010 (UTC)
- Tony apparently had an altogether different idea. Greg L (talk) 18:08, 26 June 2010 (UTC)
- The film industry has changed the way "3D" is rendered, and people like it. This issue came up at WikiProject Films, where (with only two objections), people agreed. I took it as consensus. Tony (talk) 13:09, 28 June 2010 (UTC)
- Tony apparently had an altogether different idea. Greg L (talk) 18:08, 26 June 2010 (UTC)
Animation size
With regard to this edit, and the accompanying edit summary (respect user thumbnail preferences) well, unfortunately we can’t when it comes to certain animations. The wikiserver code has undergone a major change in the last several months. Animations that exceed a certain size, as calculated by (frame-size × number of frames), no longer function unless they appear in their native size. Apparently you didn’t even notice that the NURBS animation no longer functioned when you finished with this version and it looked like this. Notice how the *animation* just sits there? The only people it would function for in that state are A) registered editors, who B) set their size preference to something other than the default value, and who C) set their preference to precisely 400 pixels. That must be less than 0.002% of our readership. This is an important detail that is really hard to overlook and I am at a loss as to why you wouldn’t even notice the effect of what you are doing; it is supposed to self-run, as shown here.
In turn, the other animations look much better when they are the same size as the NURBS animation. In fact, the Theora (click-to-play) animations are all native at 400 pixels (one of the standard sizes for Theora videos) and look much better when they are all the same size. Things were done for a reason as regards image sizes; not the least of which is making sure they actually work. Thanks for trying to improve things, but really, the vast majority of our readership are I.P. readers who don’t have user preferences option for image sizes; the important thing is to ensure the animations work and that the page layout is harmonious and attractive. Greg L (talk) 03:38, 26 June 2010 (UTC)
- To be quite honest I'd rather that we used proper videos for these animations rather than GIFs (which were a great technology in 1995, I suppose, but are hardly the best option we have today). That said, I don't disagree with the arguments given. However, I do disagree with the moving of the caption code back into the article body. It is largely nonsensical if the image is unavailable (such as for spoken / screen-read presentations) and goes into rather excessive detail regarding hwo the interface works to really be of that much interest to the reader anyway. Chris Cunningham (not at work) - talk 15:14, 26 June 2010 (UTC)
- Electronic encyclopedias get a disproportionate share of attention-deficit-like reading. It is better technical writing practice to keep captions succinct but have *hook* value to make skimming through the article an enjoyable experience and encourage reading the body text. This is standard practice in all technical writing and learning materials. Go break open a copy of World Book or Encyclopedia Britannica; you will never see expansive and tedious captions that go beyond what is required to convey a single, basic concept as simply as possible. Greg L (talk) 18:12, 26 June 2010 (UTC)
- I don't see any rebuttal to the argument that it makes the prose nonsensical if the image isn't visible. I agree that having long captions is suboptimal, but the best solution would surely be to rewrite the accompanying text so that it stands alone rather than tying it to the image. For the most part there is no reason that we need to explain how the interface works. Chris Cunningham (not at work) - talk 12:42, 28 June 2010 (UTC)
- Quoting you: For the most part there is no reason that we need to explain how the interface works. Geez, I couldn’t disagree more; the user interface and interaction of the Drafting Assistant and how it works is central to understanding what makes this CAD program distinctive and makes Cobalt so easy to use. Quoting you: …if the image isn't visible. What animation does not have a preview image for you?? What OS and browser are you using? What versions of both? Greg L (talk) 15:40, 28 June 2010 (UTC)
P.S. How much familiarity with CAD programs do you have? Which ones do you use? Greg L (talk) 16:34, 28 June 2010 (UTC)
- Quoting you: For the most part there is no reason that we need to explain how the interface works. Geez, I couldn’t disagree more; the user interface and interaction of the Drafting Assistant and how it works is central to understanding what makes this CAD program distinctive and makes Cobalt so easy to use. Quoting you: …if the image isn't visible. What animation does not have a preview image for you?? What OS and browser are you using? What versions of both? Greg L (talk) 15:40, 28 June 2010 (UTC)
- My experience with CAD programs, user interfaces or any other technical expertise has nothing to do with this debate. The animation would not be visible in a spoken version of the article or in a derivative which didn't include the images, and it wouldn't animate in a printed copy of the page. It is precisely to avoid losing clarity in such derivatives that images should be encapsulated and article prose shouldn't depend upon them. Chris Cunningham (not at work) - talk 17:19, 28 June 2010 (UTC)
- Quoting you: My experience with CAD programs, user interfaces or any other technical expertise has nothing to do with this debate. Again, we agree on something. I can not fathom why you would write about how animations would not be visible in a spoken version of the article or in a derivative which didn't include the images, and it wouldn't animate in a printed copy of the page. Sorry; I can’t help you. Please go fight your battles against animations somewhere else; this is not the proper venue. Animations that A) show how the program works and B) show what kind of animations the program can generate, are more-than germane and topical to this subject. Greg L (talk) 17:22, 28 June 2010 (UTC)
- The matter in question here is not the presence or absence of animation; it is that the article prose makes inappropriate references to the accompanying images, which may or may not be present in derivative works. This can lead to said text being nonsensical. Ideally, images should be encapsulated so that article text does not refer to them directly and any direct explanation of the image is left to the caption. In this case, the prose in question is too long simply to be moved there, so needs to be rewritten. Chris Cunningham (not at work) - talk 17:39, 28 June 2010 (UTC)
- Quoting you: the article prose makes inappropriate references to the accompanying images, which may or may not be present in derivative works. Your objection to the gallery started out with the premise that it is a random collection of images, which aren’t allowed. I proved that to be fallacious. Now I find myself chasing you as you flit around trying to find traction with some sort of argument. What “inappropriate references” and “derivative works” are you talking about? Greg L (talk) 17:45, 28 June 2010 (UTC)
- "Derivative works" includes spoken versions of articles. "Inappropriate references" include text like "In the animation at right". The gallery objection has nothing to do with this. Chris Cunningham (not at work) - talk 17:47, 28 June 2010 (UTC)
- Animations are allowed on Wikipedia. Objecting to them because they are incompatible with “spoken versions of articles” is an opinion that isn’t shared by the rest of the Wikipedian community. Go take up your objection somewhere else, please; this isn’t the proper venue for your complain. There is nothing wrong with directing the readers attention to a specific animation when there are more than one on the page. Greg L (talk) 17:58, 28 June 2010 (UTC)
Once again, I don't have any problem with the use of animation here (if I implied that I did it was an accident). The problem is the use of the article prose as a surrogate long caption for the image. That's not explicitly prohibited by the MoS, but it can cause a loss of clarity (and make it harder to create derivatives) for no really compelling reason. I might have a try at reworking the text in question to resolve this myself, though I doubt it'll be today. Chris Cunningham (not at work) - talk 18:06, 28 June 2010 (UTC)
- There is nothing wrong with directing the readers attention to a specific animation when there are more than one on the page. The verbiage describing and elaborating on the animation is too extensive for a proper caption; it is far better to have the descriptive text broken up as separate paragraphs in body text rather than an enormous caption. If someone wants to use that animation in another article, it’s simple: they can borrow whatever text they think is appropriate for the new use. We’re just going to have to agree to disagree on this one; gigantic captions are simply avoided in all good technical writing. If you can’t let this go, then I suggest you solicit Tony (who is the only other editor around here active on this page) what he thinks. Greg L (talk) 18:15, 28 June 2010 (UTC)
A few minor questions
This is impressive writing. A few points, though:
- "detailing" alone seems vague compared with the more specific terms that surround it (engineering features, surfacing tools, etc.). Detailing of what?
- "Associativity" ... hmmmm!
- I'm no fan of the long superscript "[Note 1]", etc.; superscripts become disruptive when longer than a single numeral, to me. But I can live with it.
- No italics for the names of computer applications? (incl. Cobalt and SpaceClaim). Again, there's no particular rule about this.
- Title case for book names? "Blend of 2‑D and 3‑D Solid Modeling Speeds Design of New Heart Rate Monitor Watch"—it's like alphabet soup, but I concede that I'm leading the charge against this, with small but increasing support by publishers.
- "often require"—more logical to write "most"?
- I removed the commas: "Cobalt’s less structured modeling environment coupled with an integral ray-tracing capability makes it particularly suitable for brainstorming and product development." Would it change the meaning to write instead: "Cobalt’s less structured modeling environment and integral ray-tracing capability make it ..."?
- Spreadsheet gets a link, but parametric doesn't. I think the former is a common term.
- "It then automatically displays"—I'm still thinking about whether "then" is required. Maybe.
- Is it necessary to bullet the list of single terms?
- Unsure why "Importantly," is necessary ... would the readership not realise the importance when they read "thus, it is easy to ..."?
- Is there more than one animation? If not, remove "at right".
- Teeth grinding at "He"! <blush>
- "Here again, Drafting Assistant enabled prompt definition"—unsure why past tense.
- "The history-driven parametric nature of Cobalt"—any way "nature" can be removed or substituted?
- and/or. The MoS denizens would freak out, but I've stood up against their objection to it. Here's another good reason to do so.
- "allows the designer to later edit"—is "later" necessary? Maybe. There are quite a few instances of this item. There's "he" again.
- Any chance of simplifying the structure here? —both of which have dependencies (holes in the block)—
- "three-dimensional"—suddenly spelled out.
I haven't yet looked at the bottom bits. Tony (talk) 17:28, 26 June 2010 (UTC)
- You seem to be pretty good at technical writing and page layout but are not experience with CAD. If you see technical-writing / ease-of-reading issues (where the specialized CAD aspects don’t make you reticent) that you think can be improved, be my guest. I will come back to this later this evening (good weather outside right now) and address the points here pertaining to the CAD. Greg L (talk) 18:17, 26 June 2010 (UTC)
Bulleted list and the same list again?
Not sure why we needed the same list twice so I merged that Tool sets section together. Probably needs more work to look right. I also removed some rather OWNery hidden comments that seemed to be suggesting that only a select few can edit the page. Perhaps I misunderstood those comments? --Jubilee♫clipman 01:48, 1 July 2010 (UTC)