Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations A negative about CC frequent updates

  • A negative about CC frequent updates

    Posted by Herb Sevush on May 28, 2014 at 12:21 am

    Much has been made of the fact that Adobe can now update and upgrade as frequently as they like, thanks to the subscription nature of CC. Yearly upgrades, from this point of view, were merely a burden necessitated by various stock reporting rules and regulations. Having now taken the jump to CC I would like to suggest that this advantage does not come without cost – and in this case the cost is documentation and order.

    The yearly regimen of software upgrades allowed for a regularly scheduled upgrade to manuals and documentation. I was once married to a technical writer and I know the time pressure they used to be under to update documentation for those yearly upgrades. Now with CC this is gone, at least at Adobe, as there is NO real documentation to update. FCP 6 came with 2200 pages of documentation spread over 5 volumes. Currently PPro comes with a PDF that’s 500 pages long with an additional 50 pages of update notes. The PDF is filled with links to video tutorials that may or may not be helpful, but nowhere is there an index to all features so now if you want to understand what every option in a given menu box does you are left to trial and error. Every new upgrade compounds the problems for a new user who doesn’t know if a feature is to be found in the main document or in one of the update appendices.

    I tried Premiere back when it first became Pro and at that point it seemed like a streamlined version of FCP, without the multiplicity of menus and crazy disorganization that was one of Final Cut’s bigger problems for novice users. However at this point PPro has truly become FCP’s successor; menu’s everywhere, organization nowhere.

    Yes, it’s nice to add new features whenever they are developed, but unless some discipline is added in, what you get is chaos. There is something to be said for a slower but more orderly development cycle.

    Herb Sevush
    Zebra Productions
    —————————
    nothin’ attached to nothin’
    “Deciding the spine is the process of editing” F. Bieberkopf

    Aindreas Gallagher replied 11 years, 11 months ago 13 Members · 33 Replies
  • 33 Replies
  • Andrew Kimery

    May 28, 2014 at 12:31 am

    Is lack of documentation really an update frequency problem or just an Adobe lack of documentation problem? Traditionally Apple’s documentation was always very good and talked about technical aspects of the process (pull down, DF vs NDF, broadcast safe, etc.,) as opposed to just telling you want buttons/features did what. I say “traditionally” because I don’t know what the documentation for FCPX is like.

  • Herb Sevush

    May 28, 2014 at 12:39 am

    [Andrew Kimery] “Is lack of documentation really an update frequency problem or just an Adobe lack of documentation problem? “

    When you have no development schedule it’s hard to have a documentation schedule. Tech writers are normally working with developers so that both on-line and print documentation is part of the cycle. With CC there is no cycle. I guess they could arbitrarily come up with a cut-off for documentation and then release it, but that assures you of having your documentation be out of date by the time it’s published.

    As is often the case, when you set out to revolutionize things, you often re-learn why things were set up the way they were in the first place. I’m not saying the speed of release is not worth the confusion, I’m just saying there’s a price for everything.

    Herb Sevush
    Zebra Productions
    —————————
    nothin’ attached to nothin’
    “Deciding the spine is the process of editing” F. Bieberkopf

  • Andrew Kimery

    May 28, 2014 at 1:04 am

    Adobe has a development schedule, they just don’t have a unified schedule like they used to. Though I’m sure for big changes they coordinate so, for example, the PPro team doesn’t do anything that breaks Dynamic Link with AE or SpeedGrade.

    The fact that PPro 7’s PDF manual is 1/4th the size of FCP 7’s just makes me think that Adobe is lax in general in the documentation department. Most of the upgrades so far have been improvements to existing features so it doesn’t seem to me that updating the PDF (and having it as part of the download when you update the software) should take too much time. It just appears that Adobe choose not to keep up as opposed to not being able to keep up.

    In the end, for the user, it’s a meaningless difference though as either way we are stuck with subpar documentation. When I first started really using PPro late last year it was maddening going between different web pages and tutorial videos when, like you, all I really need was a well put together and thorough PDF manual.

    For example, when using the autosyncing feature to make multicam clips I like having options so I can tailor things to my needs but damned if I could find a single, clear piece of documentation from Adobe explaining the different options and examples of why I might want to use A versus B.

  • Craig Seeman

    May 28, 2014 at 2:11 am

    The FCPX 10.1 PDF doc is 474 pages including Glossary. It’s updated with each feature update.
    Some of the tutorial makers (Ripple Training) have access to the betas so they have their material updated at release or very shortly thereafter.

  • Herb Sevush

    May 28, 2014 at 2:33 am

    [Craig Seeman] “The FCPX 10.1 PDF doc is 474 pages including Glossary.”

    Do you find it satisfactory?

    Herb Sevush
    Zebra Productions
    —————————
    nothin’ attached to nothin’
    “Deciding the spine is the process of editing” F. Bieberkopf

  • Herb Sevush

    May 28, 2014 at 2:39 am

    Craig –

    Let me amend my question – Does the FCPX PDF explain every option of every menu and tool within FCPX?

    Herb Sevush
    Zebra Productions
    —————————
    nothin’ attached to nothin’
    “Deciding the spine is the process of editing” F. Bieberkopf

  • Craig Seeman

    May 28, 2014 at 2:58 am

    All the functions are explained. What’s not in there are workflows. That’s why there’s a heavy reliance on outside tutorials.

    Example of some of the terse information. This is from Conforming Frame Rates

    • Floor: The default setting. Final Cut Pro truncates down to the nearest integer during its calculation to match the clip’s frame rate to the project’s frame rate.

    • Nearest Neighbor: Final Cut Pro rounds to the nearest integer during its calculation to match the clip’s frame rate to the project’s frame rate. The Nearest Neighbor option reduces artifacts at the expense of visual stuttering. Rendering is required.

    There’s no example and only the briefest explanation of what Nearest Neighbor does. Everything is in there though.

  • Gary Huff

    May 28, 2014 at 3:41 am

    I never consult the documentation, haven’t in years. Much faster to google search what you are looking for. Like Craig mentioned, if often just gives a blurb with not much depth, but this was a problem with documentation for a long time before I stopped using it…one of the reasons I started turning more and more to google.

  • Andrew Kimery

    May 28, 2014 at 5:02 am

    Apple’s old documentation was almost encyclopedic, it was great. Alex Van Hurkman’s manuals for Color were required reading for the workflow best practices alone.

  • Walter Soyka

    May 28, 2014 at 12:11 pm

    Herb, Adobe doesn’t have the same synchronized and fixed release schedule that they did with Creative Suite, but obviously they still have a development process in place. There is no reason that documentation couldn’t happen along with development.

    Correlation isn’t causation. I don’t think that rapid updates are responsible for bad documentation. I think that undervaluing written documentation and overvaluing video tutorials is.

    For what it’s worth, I’ve found the quality of the Adobe documentation for any particular product to vary considerably depending on who is responsible for it.

    I’d suggest filing bug reports against the documentation when it’s bad.

    Disorganization is a harder and separate problem. I think a lot of choices about where to put things in the UI are meant to be consistent with the way it has been done before. Preserving some legacy organization is a good thing because it means that current users will already understand how to find the features (making them highly discoverable), but it becomes a bad thing when the original organization no longer makes sense. A certain degree of complexity is necessary for controlling a large amount of functionality, but this shouldn’t be the same as outright disorganization.

    Of course, the way to to fix disorganization is to re-organize — but as this forum can attest, users don’t always like change.

    Walter Soyka
    Designer & Mad Scientist at Keen Live [link]
    Motion Graphics, Widescreen Events, Presentation Design, and Consulting
    @keenlive   |   RenderBreak [blog]   |   Profile [LinkedIn]

Page 1 of 4

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy