Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[audioriver]

I think that MC's vast feature set truly means that it has no direct competitiors.  I also think this vast feature set begs for a simple, tasks-oriented user's manual that is NOT a Wiki or committee-sourced product.  This manual should appear in the "help" menu of MC and and not be something that needs to be downloaded separately.

Also agree on the need of an offline manual - preferably a complete, context-aware one like this (which is also instantly available as a .chm file within the application by pressing F1, in the exact same form and completeness).

[rudyrednose]

I disagree slightly on the offline part for the manual.

I thing the F1 key is a good idea, bringing you to context-sensitive info, and this info should start with a prominent link at the top of the page to an evergreen live manual (for the current "in development" version), and a definitive "canned" manual once the JR version in-use is not the mainstream offered as main download (v21 after august, v22 after august 2017).

And those "live" manuals should have a download link to a pdf AND ebook "version of the day" for offline consumption (with the generated date at the bottom of each page).

And the manual should have some chapters covering sample uses of more specialized aspects, like TV, networking client/server, particles, zones, DSP for multi-channel (2.0, 2.1, 3.1, 5.1, 5.2, 7.1, 7.2 and others), DSP for room correction, DSP for active filtering in per-driver amplification.

Would be nice to also have within the manual links to Youtube segments 

[CountryBumkin]

I would like to see the Wiki reconfigured so that the main Wiki view page (the one when you click "Support>Wiki") is setup in a tree-like configuration matching the exact look of the tools>options settings page in the MC  program. What we have now is horrible (sorry).

Then when you are curious about what some setting does you just go to the Wiki start page and click (on the matching icon in the wiki) say you click "General" and that opens to a new gage with an exact match of the settings you see in the MC program at "Tools>Options>General" and then you click on some setting there (say "features") and that opens a new page that shows the same view as the program but/where you can then click on a feature or setting and a new page opens explaining exactly what that that setting is for (it can have internal links to other pages. etc.). User could contribute to the "explanation of the feature/setting and put in links back to threads on the forum or where ever.

The rest of the Wiki can stay as is if you want -- but the current page setup is not very helpful for someone just starting out with MC. For example you open the Wiki and there are groupings of topics alphabetically, but under "B" there is nothing on "Bitstreaming", under "D" there is nothing on "DSP" etc..  IMHO.

Example of what Wiki page would look like...

[JimH]

This is the landing page for the Wiki:
http://wiki.jriver.com/index.php/Category:Frequently_Asked_Questions

It's an index.  Why is that horrible?

[DJLegba]

Because that's not how most people think. I think CB has a very good idea here.

[glynor]

I think CB has a very good idea here.

One that would be nigh impossible to maintain without a full time support person maintaining the Wiki.

[DJLegba]

One that would be nigh impossible to maintain without a full time support person maintaining the Wiki.

Which could be very good for business.

[CountryBumkin]

This is the landing page for the Wiki:
http://wiki.jriver.com/index.php/Category:Frequently_Asked_Questions

It's an index.  Why is that horrible?

Well horrible is an exaggeration.
Actually the Wiki is 100 times better now than when I started using MC. But I'm mentally-Wiki-challenged too. I can't  usually find anything I want - so I ask in a posting (then the next guy looking for the same thing needs to ask in a post, and so on).

For example, say I want to know what "ASIO" is. So I go the Wiki, there is nothing under the listing of "A" subjects. Then I enter ASIO in the Search box, that comes up with 12 or 15 links (most are to old release notes) and the first link/page says the information on the page is "Outdated", then the second page/link says its "Depreciated"... and I work my way down the links.

I know there is a lot of stuff to cover and keep updated (thanks to those that try). I'm just suggesting a different way to offer the information.

[blgentry]

I have to agree that the Wiki's layout could use some work.  The scenario CB just described has been my experience many times.  So now don't even bother to search in the wiki.  Instead I search with google and jriver wiki as keywords.  I can normally find what I want based on that.  But you have to understand that I've read something like 75% of the wiki, so I usually know what I'm looking for these days.

I volunteered to help with the wiki a while back and I never did anything about it.  Maybe I should contact Glynor and see if we could make some minor test changes to the layout as a start.  Just an idea.

Brian.

[JimH]

Which could be very good for business.

I doubt it.  Think about how often people ask questions that are already answered in the wiki or on the forum.  No matter what is written, or how it's written, there will still be questions asked.

I get 5 or 6 questions a day about licensing, for example.  Try a Google search for JRiver license.  It gets the right pages immediately.

It's just the nature of the beast.

[JimH]

... say I want to know what "ASIO" is. So I go the Wiki, there is nothing under the listing of "A" subjects. Then I enter ASIO in the Search box, that comes up with 12 or 15 links (most are to old release notes) and the first link/page says the information on the page is "Outdated", then the second page/link says its "Depreciated"... and I work my way down the links.

I think someone has been a little too liberal in labeling the pages outdated.  Most of the content is accurate.

Edit: I just removed the "outdated" tag.  I think the article is accurate.

Again, a Google search for JRiver ASIO turns up the right pages.

[DJLegba]

I doubt it.  Think about how often people ask questions that are already answered in the wiki or on the forum.  No matter what is written, or how it's written, there will still be questions asked.

I get 5 or 6 questions a day about licensing, for example.  Try a Google search for JRiver license.  It gets the right pages immediately.

It's just the nature of the beast.

Well you can continue to refer people to Google or the Wiki 5 or 6 times per day, or you can think about why so many people are having trouble with licensing.

I just did a Google search for JRiver license and as you say, the information is all there, and many people will have no trouble finding the information on those pages. But that's a long page of text, and the layout looks a little daunting and there are links that can quickly lead you to pages that don't look very friendly at all. And how many times do people ask you about "j rivers" or spell license incorrectly? You know how to find the information because you know how it's all organized, but knowing to search for "JRiver license" is more than half the battle, and many people don't get that far.

[glynor]

If I flagged it Outdated (and it was probably me), then there was SOMETHING on the page that did not pertain to the current version, and was more complicated than a simple tweak to fix. Outdated does not mean useless. It just means some stuff is slightly inaccurate for current versions. And it flags them in a list to come back to them later. Which I do sometimes.

If it is totally bad, I use Deprecated.

If memory serves, the ASIO article has stuff in there about settings that no longer exist in current versions of MC.

[jgreen]

A large portion of potential customers have no interest in going online for help.  Not to a wiki, not to a forum.  If JRiver isn't interested in making a small effort to accomodate these people that's fine, but they are your potential customers. 

These people come on the forum regularly and say something to the effect of "I almost gave up trying".  For every one of those how many actually did give up trying?  I believe there was one if not two of those in the "competitive disadvantage" thread.

It is a simple thing to write an introductory letter that SHIPS WITH THE SOFTWARE.  A quick start guide that explains simply the steps to playing audio, playing video, how to import (and why) and how to manage the library.  And then links to the wiki and the forum.

The forum is a great resource.  But when I've tried other software, if I have to go online to ask a basic question about getting the software to run, I'm more likely to go online and look for alternatives.

I have great respect for the technical expertise of the people at JRiver, on the forum, and in this very thread.  But in each of those groups there are people who have fallen in love with the technology and turned away from the customer experience. 

[imugli]

My question with a separate manual is who is going to maintain it?

The wiki isn't completely up to date, and if I ask myself whether I want Jim and the guys maintaining a manual or improving the software, I know which one I'm choosing.

Asking (expecting) anyone else to do it is going to lead to the same place as the wiki - Glynor and others do a great job when they have the time / inclination, and it's never going to be completely up to date...

[jgreen]

The simple steps for playing music or playing video haven't changed in the ten years I've been using the software.  There are plenty of potential customers who are going to pass on the trial because there's no clear and simple explanation of how to do that.  Those people have money to spend. 

[JimH]

It is a simple thing to write an introductory letter that SHIPS WITH THE SOFTWARE.  A quick start guide that explains simply the steps to playing audio, playing video, how to import (and why) and how to manage the library.  And then links to the wiki and the forum.

We already do something like that.

When we email customers, both before and after they purchase, we include this link:

Getting Started.

[JimH]

If I flagged it Outdated (and it was probably me), then there was SOMETHING on the page that did not pertain to the current version, and was more complicated than a simple tweak to fix. Outdated does not mean useless. It just means some stuff is slightly inaccurate for current versions. And it flags them in a list to come back to them later. Which I do sometimes.

If it is totally bad, I use Deprecated.

If memory serves, the ASIO article has stuff in there about settings that no longer exist in current versions of MC.

I think it might be better to just let the content speak for itself.  I don't even know what deprecated means, but it sounds bad.  When people see something like that it's a warning not to read it.

[JimH]

Well you can continue to refer people to Google or the Wiki 5 or 6 times per day, or you can think about why so many people are having trouble with licensing.

I don't refer them to Google or tell them to read the wiki.  I sometimes give them a brief answer, and I always refer them to this page:
http://wiki.jriver.com/index.php/Restoring_a_License

That page is linked from our FAQ, from the Support Page, from our e-mail, etc.

The vast majority get it without asking.

For the rest, we have told them in our messaging, but some people miss it.  That's normal and can't be helped.

[JimH]

And, just so you know, all this stuff I'm telling you is auto-generated by a bot.  You can ask it anything or tell it what you think and something semi-intelligent will come back.

[mattkhan]

a task oriented manual is ultimately a documented workflow for some particular process/operation
the reason to write a manual like this is because the workflow is complex and/or not obvious so users aren't getting it
if this is the case then that manual is really a set of requirements for the new UI that makes that easy/obvious so that users do get it and no longer need a manual

so ultimately IMV the "we need a manual" is really just the UX issue again

[JimH]

Split Customer Experience

[glynor]

I think it might be better to just let the content speak for itself.  I don't even know what deprecated means, but it sounds bad.  When people see something like that it's a warning not to read it.

Deprecated means no longer valid or applicable, in this context. That use is customary in technical documentation for features and APIs that only have historical value, and may no longer function as described in the documentation (or at all). I only flag articles with this if they've been superseded with other(s) or are completely irrelevant to modern versions. The Template includes a way to link to the new documentation, and I basically always use it, if the new documentation has been written or there is a good forum thread for it (unless the "whole thing" is no longer valid).

Outdated means what it says:

Outdated: This content is outdated currently, and may no longer be fully accurate. You can help the JRiver Wiki by updating it.

The ASIO article hadn't had a substantial update since 2011 when you originally wrote it, Jim. I'm not sure why I flagged it as such, though I suspect it was this line:

ASIO4ALL is a publicly available driver that accepts ASIO output and converts it to Kernel Streaming.

We generally recommend against using ASIO4ALL which provides no substantial benefit (and a lot of additional complexity) over either WASAPI (on Vista and newer) and/or Kernel Streaming (on XP). In this instance, I'm sure I was also mainly flagging the article so I'd come back to it someday and give it the once-over, as I did with the WASAPI and related articles (I'm sure that's when I did it).

I'm okay with the flag being removed from that one, though it is a pretty lightweight article for such a substantial feature. Template:Incomplete would be more appropriate anyway.

There are plenty of articles that fully deserve the Outdated flag, though. Like this:
http://wiki.jriver.com/index.php/View_Files_and_Libraries

Most are otherwise good articles, that include some inaccurate or old information, like (your commonly-referenced):
http://wiki.jriver.com/index.php/Moving_Files

Which includes instructions that do not work at all, and could lead users astray:

Library Tools / Find and Replace

Find and Replace will let you change any part of any field. If you do this in "File Location", you can change "C:" to "D:" or "C:\Music" to "C:\Video". MC will move the files and update its library.

But please note that for moving files (even with find and replace) it's better to use the Rename, Move, and Copy Files tool.

You can't do that anymore, and haven't been able to do so for at least a year or two. Find & Replace only allows you to alter a select set of fields, and [Filename] is no longer one of them. It isn't needed, because RMCF has a Find & Replace Template.

Sometimes I have time to fix them right then. Sometimes I don't, so I mark them for later, and add a mild warning that some of it might be outdated.

If you want to help fix them, visit:
http://wiki.jriver.com/index.php/Category:Outdated
http://wiki.jriver.com/index.php/Category:Incomplete
http://wiki.jriver.com/index.php/Category:Articles_in_need_of_cleanup

[glynor]

I've made my thoughts on the general matter as it relates to JRiver plain enough previously, and don't feel the need to rehash it here. But this, said as a generalized statement, deserves some response:

a task oriented manual is ultimately a documented workflow for some particular process/operation
the reason to write a manual like this is because the workflow is complex and/or not obvious so users aren't getting it
if this is the case then that manual is really a set of requirements for the new UI that makes that easy/obvious so that users do get it and no longer need a manual

I agree with this in some instances.

In others, I strongly disagree. Photoshop needs substantial documentation, but not because the UI should be simplified. You can do that, if you're willing to neuter the application. But if you want it to remain a powerful professional application, you can't always do that. I've never seen a capable professional NLE, or DAW, or programming IDE, that doesn't need at least some documentation.

MC falls much more into the latter category than it does to things more akin to Apple's new Photos app (as an example). Oh, and even it has pretty substantial documentation.

Mostly I update the Wiki to save my own frustration. Yes, it is true that many users will ask and not read it. But quite a few do as well (they post that they did when they have additional questions). And if they don't, then, at least, my reply can be a two line "read this: LINK" rather than a big explanation, which shifts over time (and perhaps contains inaccuracies based on my state-of-mind at the time).

[mattkhan]

I've made my thoughts on the general matter as it relates to JRiver plain enough previously, and don't feel the need to rehash it here. But this, said as a generalized statement, deserves some response:

I agree with this in some instances.

In others, I strongly disagree. Photoshop needs substantial documentation, but not because the UI should be simplified. You can do that, if you're willing to neuter the application. But if you want it to remain a powerful professional application, you can't always do that. I've never seen a capable professional NLE, or DAW, or programming IDE, that doesn't need at least some documentation.

MC falls much more into the latter category than it does to things more akin to Apple's new Photos app (as an example). Oh, and even it has pretty substantial documentation.

The context for my comment came from the competitive disadvantage thread which has numerous people commenting that relatively basic functionality is somewhat obscure from a ux perspective, documentation is hard to find and/or often out of date and the capabilities of the product are not easily discoverable.

IMV starting on a simpler/more cohesive/discoverable ui for common tasks is going to add value to more people than a detailed manual. Of course writing that manual may make it easier to see the app from a new users perspective, documenting workflow often makes you realise how inconsistent/convoluted it is.

Good IDEs (jetbrains apps for example) are actually a good example of this, they do have a manual but you don't have to refer to it v often (often means you are doing something really quite obscure if you can't work it out easily). Note that this assumes a certain understanding of the domain, teaching people about that domain is a different thing to a reference manual after all (though one you might address in the same sort of way, i.e. a UX that makes it easy to "do the right thing" where right thing = how you want people to use your product)

[dtc]

We already do something like that.

When we email customers, both before and after they purchase, we include this link:

Getting Started.

Unfortunately, once you drill into Getting Started, you get a lot of pages with "This article is a incomplete. It is missing detail about critical functions, or contains a number of red links. You can help the JRiver Wiki by expanding it." at the top of them, for example with such simple pages as Standard View. And pages like Categories and Panes and Player Bar do not exist. That is kind of rough for a new user.

[ssands]

It's been said before but at a minimum every option /menu item / right click need to be described.
Then major capabilities that require multiple options selected and work flow also.  Searching the forum is not a good way to disseminate thus type of info.

[blgentry]

The REAL question is this:  What types of customers does JRiver want for MC?

The current model of wiki based documentation with a UI that is complex self-selects the customer base.  Those who need simple and easy probably go elsewhere pretty quickly.  Those who need hand holding probably similarly abandon ship quickly.

People who like complex interfaces or who like discovering and learning about a product as they go along probably stay.  If JRiver wants more entry level customers, then yes, further documentation would probably help.  As would some UI refinement, as has been suggested in many, many other threads.

I suspect that JRiver's staff kind of likes that the types of people that MC attracts tend to be more "self service" oriented than your average audio consumer.  So I think that some of these choices are (at least subconsciously) intentionally designed to cater to a certain type of customer.  I'm completely speculating here, so I could definitely be wrong.  No insult intended to anyone.

Brian.

[Vocalpoint]

Unfortunately, once you drill into Getting Started, you get a lot of pages with "This article is a incomplete. It is missing detail about critical functions, or contains a number of red links. You can help the JRiver Wiki by expanding it." at the top of them, for example with such simple pages as Standard View. And pages like Categories and Panes and Player Bar do not exist. That is kind of rough for a new user.

Agreed. An introductory email is really missing the mark if it mentions (or links to) anything that is "outdated" or "incomplete".

EX: The entire "Servers" link dates back to MC15...no real sizzle there - at all - to get excited about.

I also find that email/page (the all important "first touch" with a potential new customer) instantly gives off a "Is this a 1995 Netscape web page?" vibe with reams of static text and nothing remotely interesting (or modern) for the user experience.

It's 2016 - the modern Internet is everywhere. Time to buff it up a bit lads.

VP

[ferday]

I suspect that JRiver's staff kind of likes that the types of people that MC attracts tend to be more "self service" oriented than your average audio consumer.  So I think that some of these choices are (at least subconsciously) intentionally designed to cater to a certain type of customer.  I'm completely speculating here, so I could definitely be wrong.  No insult intended to anyone.

Brian.

also without insult intended, i agree with this blgentry.  truthfully it's a big reason i try to be active in the forums...because i (subconsciously or not) prefer the higher end user base from a technical point of view (and often learn something myself in the process of trying).  i know that when i've asked for help, i've more often than not been lead towards the path rather than spoon fed the answer...which i have really enjoyed!

but that said, some things are "basic" and don't change...like how do i get media in, and how do i get it out.  how many "various artist albums show up as separate albums" questions can one forum bear...

[imeric]

We already do something like that.

When we email customers, both before and after they purchase, we include this link:

Getting Started.

Just looked quickly and as per Jim's above The TV Stuff on EPG is outdated...

IMHO:

All the info is on interac but it's like finding a needle in a haystack when you want to do something not on the wiki...(confusing even for experienced users).

There has to be a way to leverage all those MC passionates to keep the Wiki up-to date?  Ask for volunteers and have an MC person supervising what gets uploaded on the wiki?  When a new feature is added or a new How-to or workaround has been found one just puts it on the wiki besides interac?

Maybe I'm oversimplifying this as I'm no wiki expert but isn't what wikis are all about?

For newbies all they really need is a quick user guide then they could refer to an updated Wiki for more details.

My 2 cents

[Vocalpoint]

There has to be a way to leverage all those MC passionates to keep the Wiki up-to date?  Ask for volunteers and have an MC person supervising what gets uploaded on the wiki?  When a new feature is added or a new How-to or workaround has been found one just puts it on the wiki besides interac?

Or they could do what other pro shops do - hire a technical writer (s) who have the time, talent and resource to whip this knowledge into shape and present it to the masses in a relevant and useful manner?

VP

[JimH]

I think there is so much enthusiasm for a manual that someone could make a lot of money if they wrote and published one.

[syndromeofadown]

I couldn't care less about a manual and I like the Wiki.
Why not outsource the job overseas. For less than the price of one cup of coffee per day you could hire someone fulltime to transfer knowledge from the forum to the Wiki and a manual.

I think there is so much enthusiasm for a manual that someone could make a lot of money if they wrote and published one.

Like JRiver? You could make a non-free app that is the manual and have paid upgrades for it yearly.

[blgentry]

Why not outsource the job overseas. For less than the price of one cup of coffee per day you could hire someone fulltime to transfer knowledge from the forum to the Wiki and a manual.

In MY opinion that's a really, really awful idea.  Please, please, please don't hire a non-native English speaker to write a technical manual in English.

The real problem though, with hiring a tech writer, is that tech writers usually aren't techs.  So they normally need one or more members of the technical staff to spend quite some time teaching them about how things work, which takes more staff resources.  It's a problem that can be solved, but it's a "cost" of doing things like this that's sort of hidden.

Brian.

[DJLegba]

The real problem though, with hiring a tech writer, is that tech writers usually aren't techs.

You just need the right tech writer. Most users aren't techs.

[DJLegba]

I think there is so much enthusiasm for a manual that someone could make a lot of money if they wrote and published one.

My wife really likes JRiver Media Center. She has no trouble selecting music or movies using JRemote. Tonight she wanted to create a playlist on her Android phone. I installed JRemote and showed her how to create a playlist. How to edit it? I don't use playlists, so I didn't really know. After futzing about for a bit I figured it might be easier on the iPad. Yeah, here's how to move things around. So she moves a few tracks and the iPad starts showing an empty playlist. OK, I've figured out how to edit a playlist on the Android phone, so I show her that. But no matter what she does, the playlist she sees isn't in the edited order. Well, I explain, the phone hasn't received the update from the server, but look, even though the tracks are listed in the order you set originally, if you press here and swipe there you can see the real order. You just won't see it on the main list until I restart Media Center on the server. I restart MC and proudly show her that the list on her phone is now in the order she expects. She gives me the stink eye. Next time I'm going to tell her to read the Wiki.

[flight16]

A large portion of potential customers have no interest in going online for help.  Not to a wiki, not to a forum.
....
The forum is a great resource.  But when I've tried other software, if I have to go online to ask a basic question about getting the software to run, I'm more likely to go online and look for alternatives.

Yes, exactly.  Me, too.  Having to register, post, clarify, wait a day or two for a good reply...  I just wanted to use your software but now you're asking me for even more investment just to figure out how to use basic functionality. 

JRiver's lack of up-to-date, context-based help is a major turn-off for me.  I eventually stopped using JRiver.  I can't remember why, exactly, but I feel like it was a combination of things, and just getting it configured correctly turned into a full-time after-work hobby and forum posting.  That was fun when I was 16.  Not so much anymore.

[flight16]

The simple steps for playing music or playing video haven't changed in the ten years I've been using the software.  There are plenty of potential customers who are going to pass on the trial because there's no clear and simple explanation of how to do that.  Those people have money to spend. 

That's an interesting point.  The people likely to buy the software have money (adults with jobs) and are usually busy with other things and want direct, well-documented help.

[flight16]

I would like to see the Wiki reconfigured so that the main Wiki view page (the one when you click "Support>Wiki") is setup in a tree-like configuration matching the exact look of the tools>options settings page in the MC  program. What we have now is horrible (sorry).

The rest of the Wiki can stay as is if you want -- but the current page setup is not very helpful for someone just starting out with MC.

Exactly!  Take it one step further and have a tiny "?" icon or link in each dialog or pane that links back to the wiki (like other apps have a "?" icon that links back to locally-installed help files).  Is this not win-win?  JRiver keeps the wiki and doesn't have to invest in writing or packaging new documentation.  And that documentation is more easily discoverable by the users.

[daveman]

Pages in the Wki still refer to MC 15 and MC18.

There are features that are not even listed in the Wiki.

Sometimes I have to search several pages to get a basic understanding of a command.

There are several options that I do not even understand as there is no simple instructions/explanation.

A F1 help feature, once created, should last for several versions as it does not appear as if you ever remove features, so once the database of instructions it is created it should last for quite a while.

A proper manual / Help feature has been requested for quite some time....

Personally, I think it would be a good investment to spend time developing this.  Ease of use as well as ease of getting information is a key feature of the best software,

just my 2 centss

[Chico]

Which is why keeping up on a Manual would be daunting at best.  MC has a tendency to update more often than most other apps.  Some updates add or remove functions and tweak the program.  MC would almost certainly have to slow down on the updates so the manual can keep up and so users aren't forced to update their manuals every week or so to keep up with each MC update.
 

[daveman]

Once a change is made, it should be incumbent on the programmer to simply document what had changed and how...

I can not see that taking so long..

Dave

[JimH]

Changes are covered in the forum.  A search for a new feature will tell you how it works.  A Google search works best.

[luker0]

This is the landing page for the Wiki:
http://wiki.jriver.com/index.php/Category:Frequently_Asked_Questions

It's an index.  Why is that horrible?

I've been at the software game for a very very long time.  That page was not helpful at all when I first started using MC, it implies that you know already what you are looking for.  I did not.

[CountryBumkin]

I wouldn't mind helping/editing/adding-to the Wiki - but I don't think I'm knowledgeable enough in all the intricacies of MC to do it. I think this is the problem with most Users that would want to help.

But if JRiver lets me, and then someone comes along after my updates/additions to check what I write (and even if they decide my contribution is garbage and they delete it - I'm okay with that), I would be happy to volunteer some time.

[JimH]

I've been at the software game for a very very long time.  That page was not helpful at all when I first started using MC, it implies that you know already what you are looking for.  I did not.

What did you expect?

[Vocalpoint]

Changes are covered in the forum.  A search for a new feature will tell you how it works.  A Google search works best.

What if a user does not come to the forum - like ever? What if said user has no idea "what" to "google" on a new feature?

These ongoing assumptions that everyone that ever might use/try/investigate MC actually cares/uses/knows about these forums....does make me wonder sometime.

VP

[JimH]

Search has replaced manuals, in my opinion.  A lot of the comments on-line (forums, product evals, etc.) is better than some of the manuals.  When I have a problem, I search.

[Vocalpoint]

Search has replaced manuals, in my opinion.  A lot of the comments on-line (forums, product evals, etc.) is better than some of the manuals.  When I have a problem, I search.

Totally understood. But it only brings value when what you are searching for - is actually timely and relevant.

Searching the MC wiki for help on a specific item and then finding references to MC15 is useless.

If you want the wiki (and search) to have any value whatsoever - when one searches it - ALL search results better be based against MC v21 (at this time) or it's simply not worth the time.

VP