Developing Multiple Artboards
Posted by: Neeraj Nandkeolyar, Workflow specialist, Illustrator team
Typically, when we start work on a new release, a list of features is put forward and each item is weighed against others on the list. ‘Multiple Artboards’ was one of the oldest entries on the list. All the forces never joined hands so it could make it into the product. In CS4, too, we had put ‘the list’ upfront and started seeking commitments from stakeholders – and gradually built consensus. One after another we started hearing an ‘aye” for Multiple Artboards in CS4. Product Management, Development, Quality Engineering, Experience Design, et al. There was enthusiasm, and this ‘old’ item on the list suddenly became exciting. The ‘Multiple Artboards Feature Team’ was born.
The multiple artboards feature interacted with a lot of other features in Illustrator. It was like going up a mountain trail with lots of different teams, each working on its feature and impacting multiple artboards when the trails intersected. Each of these features had its own needs from mulitple artboards. Illustrator’s capable pre-release users helped us prioritize these multiple asks. They guided and helped the team correct some approaches as well.
For example: the feature team decided to reduce the canvas size to 14400 x 14400 pts from 16383 x 16383 pts owing to PDF 1.5 standards. For older files, an ‘Enable Oversized Canvas’ was added. There were arguments in favor and against, but our team couldn’t decide. But advice from the pre-release users changed things: “Would you get more tech support calls asking what is ‘ Enable Oversized Canvas’ or more calls for not saving the big artboard to PDF 1.5”? The team decided to go back to the traditional canvas size.
Time passed by, features were shaping up nicely, and there were good feelings all around – it was time for Uncle Murphy’s visit. Just after all features were marked ‘done,’ the QE team broke free from the trail and started wandering around. They started testing multiple artboards with older Ai versions – and a plethora of issues started cropping up. At one point it almost shook our confidence and we thought of reducing the scope of the feature.
Both Development and QE started ‘combing’ through the features. Product Management assessed risks with each issue, Engineering worked towards finding a solution to issues, getting approvals and then making code changes after multiple reviews. QE verified those changes, and made further aggressive attempts to find more issues. Multiple SWAT teams were formed to track changes. With a combined and dedicated effort, and keeping aside the luxuries of life (at times necessities, too), we got back to the state where the trails became smooth and the teams regained their confidence. That bunch of people who had started together and taken different trails, finally joined back on the other of the mountain – happy and confident.
Working late nights and weekends, surviving on pizza and caffeine, having group discussions, and making quick strategies and plans… all added to the ‘adventure’ of developing multiple artboards. It was fun.
Did you like this post? Would you like to hear more from about the feature development process? Let us know.