Notes
Contents
S-7: Video + Architecture
S-6: Data Integration + Architecture
S-5: Multi-generation plan
S-4: API Layer; SSO; Transition
S-3: Article Ingestion; Dashboard API
S-2: Login; Dashboard; Article Creation; Media Library
S-1: Dependencies; Area to build first; Article
Comments
S-7: Video + Architecture
Video Process
  • All the tagging has moved to Toolbelt
  • User creates/clips the video in Grass Valley products, and uploads/saves the file into the shared network drive
  •  Then, user creates Video asset in Toolbelt, and the video file and image file that have the same title get picked from the drive. User also inserts video metadata through Toolbelt.
  • After published, the video goes through VCPS (Video Content Publishing System). VCPS has all the setup to inform encoder.
  • Pass-through allows the users to publish out the story with the video reference without having the entire encoding to be done. Once the pass-through is done, the video gets published to MPX and the site. As the encoding gets finished, VCPS informs MPX that other various formats are available.
  • Video ID gets shared between Toolbelt and VCPS.
  • Editor fills out the metadata of the placeholder asset with the in and out time and marked it as scheduled. Video editors then clip the video and attach the video and mark it as edited. Video producers reviews and publishes. When the video is available, video team informs the editorial via Slack.
  • Goal is to make the video process to be under a minute -considering adding high–priority flag to expedite the process
 
Video Integration
  • Video service component is going to stay as a separate service
  • End Goal is to remove the VCPS layer, but for now, keep Toolbelt in sync with the metadata, and BEE can communicate with VCPS directly. Accessing shared network drive is easy.
  • Basic video editing is in phase 2 of multi-generation plan
  • Any videos or images that are being uploaded through CMS will be available for the others to use in the article.
  • All the video formats should be identified: .mp4
Toolbelt – BEE
  • Certain Toolbelt data would be available from BEE, e.g. Person (Donald Trump), Company (Apple, Inc.), etc.
  • Push model: any type of look up or data that are needed would be pushed to BEE as necessary. BEE will cache the data, accept notification, and refresh the data.
  • Data types that would need the push model for:
    • Section, tag services
    • Layout (templates)
    • Organization services (Team, Project)
    • Media service (Image, Video metadata)
    • Any other data that has dependencies, e.g. Person
Deliverables
  • Architecture diagrams
  • Evaluation of the services from both sides
  • Risk matrix
  • Order of operations
  • Level of estimation for time
  • Man weeks/timeline
  • NOTE: CNBC currently has 4 developers with regular maintenance work to do / could ask more resources if needed
Content/data type/feature details
  • Favorites
    • Favorites can be retired from Toolbelt, but that info needs to be served to Toolbelt from BEE
    • Any other editorial content would come back to Toolbelt – all CRUD operations
  • Audio
    • Upload audio file – can simply be represented as file in the system
  • Chart
    • Users can upload .csv file or modify in CMS
    • Reference market data and create table
    • Uploading graphic figures
    • Need to identify where it goes and follow the right business rules
  • Gallery
    • = Slideshow that is collection of images
  • Author
    • Roles would be figured out during the user login phase
  • Search
    • There is a global search available at the top at all times
    • Search would go to Content API/DPIM’s search, using robust search, e.g. ElasticSearch
    • Would have to do small migration to BEE and index the content. Indexing system would require push from both systems. Currently Toolbelt has a push mechanism for content distribution system
    • CNBC won’t implement the new search into Toolbelt
    • Saved search: user can save the queries that they use often
      • Need to define how many saved search can a user create – the limit can be configurable
    • Recent search: User’s most recent search
  • Video
    • Clip video: possibly use 3rd party services. Important to open the clipping service to all the users to easily do basic edits, e.g. Snappy
    • Bigger topic and contingent on video team – leave out from the estimate
  • Article fields
    • Shown/hidden based on the role
  • Publish & social
    • Publish article first and then add the link to Twitter
    • Currently integrated with SocialFlow to publish out sequentially
    • User should get confirmation when the Tweet gets out
  • Homepage banner & mobile notification
    • Urban Airship is sending the mobile notification and email
    • Banner is taken care of in Toolbelt
  • Preview
    • Link provided from Toolbelt
  • Autosave data
    • Undo can be done through the browser
    • Consider how often should the save happen – ideally every character
    • Consider how many revisions to save – Latest version is sufficient for the use case of retrieving the lost work
    • Estimate the effort/cost for different levels of autosave and determine the business value
  • Chat
    • Article-specific
    • Integrate with Slack to invite/add user into the edit screen
  • Security & Company
    • Integrate with GDS, stores a reference ID
    • Currently in Toolbelt, symbol lookup is called when Security & Company are embedded into an article – generates links to the market data page
    • Sync with GDS every 1 hour
  • Source
    • e.g. CNBC US, CNBC Europe, New York Times, etc.
    • User can create new Source in the CMS
  • Wire Stories, Partner Stories, Press Release
    • 3rd party wire service automatic ingestion
  • Presets
    • Pre-filled fields of content types
    • User can define and create new presets
  • Section
    • Even though there are editors who are mainly managing the sections, but they should be manageable by any user
    • Consider like association/taxonomy/tagging
  • Collections
    • Should consider the association between collections and templates
  • Wild Card
    • Generic page, e.g. About page
    • Embed code
S-6: Data Integration + Architecture
Overall Architecture
  • Benefits of having Content API between CMS and Toolbelt:
    • News API is already built and set up
    • BEE needs to be dynamic product – add content, remove field, etc. This structure decouples BEE from the storage
  • We would need to work out what Content API has and hasn’t for Toolbelt
 
System Sequence
  • Video
    • Stored in Akamai for Video delivery
    • Metadata in Toolbelt
  • Image
    • Stored in Media Server
    • Metadata in Toolbelt
  • Can BEE send media files directly to Akamai? This would make the process faster
    • Not a simple process, as video encoding process is triggered before the Akamai
    • Toolbelt has placeholder node, and the editors would choose the video from shared network drive
  • Images & Videos metadata include file references as well
  • Videos need to be discussed in a separate session
    • Hook into the Video APIs
  • Authentication such as OAuth will be used to communicate between Content API & Toolbelt
  • Data format
    • Toolbelt does not have robust data model right now, but currently building a data model
    • Content API needs to use the same data formats, so we might have to build layer between Toolbelt and Content API to transform the data formats
    • Downside of Content API: everything was custom field
  • EDIT: Multi-user edit would be a different workflow
    • 2 people and more – serve the content from BEE
  • PUBLISH/SAVE/PREVIEW
    • Content API doesn’t support multiple states, only publish. Additional states would need to be built
    • All the push/publish calls would need to be built, because Content API only has read
  • REVERT/SWITCH VERSIONS
    • How would the users know which versions are available?
      • Need to retrieve all the list in Toolbelt
  • SEARCH CONTENT
    • Look into if Content API has content storage or caching
      • Currently treated as a transformation layer
    • Toolbelt Search is slow – MySQL query
      • Benefit of the Content API would be to improve the search speed
      • Even if all the contents are coming from Toolbelt, we should start storing them in Content API for faster speed.
    • Look into ElasticSearch – What Content API can store and supports with search
  • UPLOAD MEDIA
    • Copy of the metadata and all the content still needs to be stored in Toolbelt, at least in phase 1, not to impact downstream
    • Images – need to crop
      • Currently Toolbelt is using local service within Toolbelt
        • Send the file or file location / focal point to this service
      • Consider using external services such as Cloudinary
      • Metadata still needs to come in to Toolbelt
    • Video – video content production system
Dashboard
  • We need to decide on how to communicate to deliver Dashboard
    • We need to start with the feature with less dependencies, which would be Dashboard
  • We need API security, e.g. OAuth
  • Dashboard would need the content IDs – we need to identify what other information that’s required on Dashboard
  • Start storing the copy in BEE is fine, but in the beginning, users should be able to favorite from both BEE and Toolbelt
    • BEE would need to both push and pull while Toolbelt is storing the data
Field Mapping
  • Primary Tag – Primary Assets: keep the functionality / users can insert article as well
  • Current Toolbelt crop is pretty static: CNBC wants the ability to add more crop sizes
    • If we use the image service
      • We simply pass the size of the crop to the library, and the crops are automatically generated
      • It would reduce storage spaces
      • Content API has such service
      • Toolbelt just stores the images and doesn’t need to do any work to generate crops
CNBC needs to know the sequencing of features
  • What to build first
  • Find out what it would take from CNBC to support all the features
    • SSO integration
    • API endpoints
    • What does that effort look like?
    • What does CNBC need to provide in order to deliver 1st phase
    • CNBC needs to develop ahead of BEE
S-5: Multi-generation plan
Multi-generation plan
  • Order can be moved around, can run in parallel
  • Phase 0
    • Infrastructure integration
    • CNBC Tech team: Build out endpoints, use Content News API as guide
    • Atlantis API (integration layer) would perform integration on it
      • Also provide endpoints for different contents
    • Need exposed API endpoint in order for the different sections to work, e.g. Favorites
    • Create mock data (DPIM)
    • Infrastructure (DPIM) < as long as standard NBCU security set up
  • Phase 1
    • Not storing a lot of user information in Toobelt currently
    • Consider adding all the necessary fields for the user for the future
    • User Data Migration – import into new system
      • Toolbelt would continue to map to the same ID
      • Make new IDs vs. use Drupal IDs
      • One-time user set up
      • Authorization & User storing happens in Atlantis
    • Don’t save the user in to places – Every action performed would be tied to the user ID – Toolbelt creates a new user if the user doesn’t exist, Toolbelt passes the user ID back to Atlantis
      • All of the user information pertinent to Atlantis should be stored in Atlantis
  • Phase 2
    • ChartBeat – what is trending on the site < Gigya / Google Trend
    • Add SocialFlow in the Statistics service
      • Combine different statistics on a single page
      • Top 10 to be constantly updated
    • Analytics page (future phase)
  • Phase 3
    • Autosave
      • Need to retrieve the autosaved version
    • Content Library would show the revision of a specific content, all the hard save and autosave revision in a single list
  • Phase 4
    • Ingest story from partners – should Atlantis be integrating the services
      • They would continue to come into Toolbelt – Atlantis comes in when someone wants to edit the wire story
      • Does Atlantis need to know the content ingested – in that case, Toolbelt should have push to Atlantis
      • Wire Story – 80% are published, the rest are in draft-unpublished
      • Service to get revisions of specific content item
      • Ingest – primary feature of Content News API
  • Phase 5
    • Can merge the TV content and shows pages content < have full episodes, etc.
  • Phase 6
    • Will impact the downstream for having the contextual caption
      • Overrides
      • Would result in more work
      • There were a confusion in Workbench
      • For MVP – stick with the current implementation
    • Native image manipulation? Would Cloudinary be reasonable?
      • Have the ability to generate thumbnails on a fly
      • All the media content on the content services currently, but this might be an opportunity to move
      • Would be a huge benefit
      • Migration effort
      • Today.com, NBC NEWS – there is a team who developed a service – March
        • potentially ditching the native Drupal image manipulation
        • It needs to be on Drupal
      • There is no image manipulation built in Content News API
      • Cloudinary – stores, transformation on demand
      • In Drupal, have to define crop ahead of time
        • Have been forced to use the existing one so far
      • Can front it with Akamai – pricing based on volume
  • Video can be its own phase
    • short form clipping, metadata management
  • Phase 7
    • Virtual to migrate to Dynamic Collection?
      • Pin top 5 and automate the rest of the list
    • Ability to change curated collection to dynamic collection
Things to add
  • Address the restructuring of parents
  • ability to clone/copy

 

S-4: API Layer; SSO; Transition
API Layer
  • Needs to be multi-directional (Toobelt – API – Atlantis)
    • e.g. Favorites – needs to be able to both pull & push API exposed by Atlantis
    • API calls coming into Toolbelt would always be on request basis
  • Decoupled
    • Content API service can provide content on a sliding scale of data redundancy from caching to full parity
    • Data from multiple sources can be hosted in a single API
      • e.g. using Cloudinary or externally hosted service – can use integration layer for single source
    • Toolbelt can be swapped out with any content management system at any time without modification of the Atlantis UI
      • Ingest layer can be swapped out as long as integration layer provides single API
  • Parallel work streams
    • Atlantis front-end can be built on top of existing Content News API
    • Migration from Atlantis to Toolbelt?
    • There is no CRUD APIs in Toolbelt
    • Does the spec for Toolbelt API have to be the same with Atlantis’ Content API?
      • No –  Toolbelt doesn’t have to worry about matching the spec with Content API, Content News API takes care of it
    • Toolbelt API needs integration layer for the single point of contact for Atlantis
    • CNBC team can build Toolbelt API up to a specific point, and API team can take care of the rest
  • There’s no need to full sync, but if the architecture supports it, there’s no reason not to do it
    • There’s a storage layer that checks redundancy, but there’s probably no need for it
  • All the content in Toolbelt will exist in News Content API?
    • It’s a passthrough caching
    • 3rd party ingested external data would not make way to Atlantis at this point
      • 70% of the content, would that be a problem?
        • When linking to the ingested, Toolbelt API should provide the searchability
        • CURRENTLY: Set up a search for specific content types
        • 1. Toolbelt UI 2. Ingestion process
    • Wire content pulled in
      • Editoral should be able to see not only the published content, but also the ones that are in draft
      • Content News API would need to support all states
      • Publish out drafted content
  • Additions can be made in Content API
SSO
  • Two-factor auth
    • Straight-forward to implement – just need SMS gateway
    • there are Drupal 6 modules
  • Toolbelt would trust Atlantis for log in
    • There’s going to be handshake, e.g. OAuth
    • It would be straightforward to implement with SAML
  • Needs to be used within the VPN
    • e.g. Dropbox – don’t need to be on VPN
    • e.g. Benefits page
  • If it’s within VPN, that’s already two-factor auth
  • Request is to not use VPN, but it has to be two-factor
    • CNBC doesn’t want to lower the security
  • Explore a way to decouple VPN and SSO
    • CNBC Tech team would need to see what Toolbelt needs to do in order to make this work
  • In a long term, CNBC would like to remove API and Toolbelt
    • Vision for the entire project should be included in the proposal
      • What does the entire scope entail?
    • From editorial pov: What features would be delivered when
    • Technology pov: Tech stack upgrade
      • e.g. Image processing technology – UI might not change, but the service it calls can be swapped out
Transition
  • How would search and syndication handle this without data migration? – e.g. if someone asks for the old content
  • Breaking News – currently a Franchise, and any content type can be Breaking News
    • Need to consider the impact that it’ll have in downstream, e.g. Application come back to show the banner in the apps
    • Can API treat Breaking News as News Story?
      • No, they have different workflow
      • Make sure that CNBC TECH to look in the downstream – would have bigger impact
      • There should be an ingestion layer for that
  • Webservice – Toolbelt has been adding more and more web services
    • e.g. If Twitter changes the way to embed – created a layer of abstraction
    • Needs further discussion
    • Abstracting the UI for it
    • Need to consider the impact on the other platforms – currently just dropping in
    • e.g. YouTube widget – all you need is YouTube ID -> hint to the web platform, and knows what embed to use and pass parameters
    • Need to explore: How widely used? How often changed?
    • This would require 2 fields: 1 for service, 1 for id
  • Webresource
    • Use Case: pull in external feeds
      • Done by Producers (mostly left), not Editors
      • Set up a module to webresource to pull in the feed from external
      • Need to explore: how many of these exist?
    • Use Case: Deal with a partner – take NYT articles and wants the link back to them
  • Wild Card gets embedded with in the article vs. Wild Card as a whole page
    • Elemental changes would be a separate thing
    • It can be an instance property
    • Consider integration layer with Toolbelt
  • For structural changes, need to consider:
    • migration
    • downstream implication
    • might have to involve other teams (web, digital distribution)
  • Byline – Creator vs. User
    • User vs. Author / Creator
  • Security
    • Matching the Company – think about the impact
    • Would exist as just an inline lookup, not as a separate type – just use the same IDs
  • Tags – there should be an ability to create them
  • Projects
    • Use Case: for Analytics
  • Retiring Product & Promotional Package
    • Can be considered as Configuration / no Toolbelt user needs to use
    • Explore: What’s going to happen downstream?
  • File
    • 3rd party related files can be removed – but file would still serve Skin types
  • Promotional Package used on right rails on the new homepage
    • MPS can do some of its functionality
S-3: Article Ingestion; Dashboard API
Article Ingestion
  • Atlantis handles front-end layer & real-time activity
  • Services layer (Atlantis)
    • Article service: actual article message, logic
    • Revision Service: needs to store e.g. transaction, revision
    • Publish vs. Save & different publish workflows
      • Hard Save & Publish (Toolbelt)
        • Publish out to Toolbelt would be saved as a revision in Toolbelt
        • Save & Publish are treated the same in the database – Publish goes to the end-user application and act as a flag
      • Autosave per session (Atlantis)
        • Field typing: Sent over asynchronously until you lose communication
        • When a user is editing a content, a version of the autosaves will be stored in Datastore. Thus, when the first user loses connection, the second user who was editing publishes the content, the first user’s changes also get written in Toolbelt.
      • Requirement to store field-level revision? – Yes, check field-by-field changes
    • Revision History
      • MVP – Storing the revision history, but building the infrastructure and UI later
      • How do we know which version is the most current?
        • Since we are start editing in Atlantis, “Work in Progress” version would be created and tracking will be happening in Atlantis
      • Not 2 ways between Toolbelt & Atlantis because the work in progress versions would be handled in Atlantis, and the revisions of hard saves will be stored in Toolbelt
  • Social Media Service
    • Does Toolbelt handle this already?
      • Existing service in Toolbelt – Atlantis can leverage and message Toolbelt
      • Review how the service is built (CNBC Tech)
    • Atlantis needs to send the message with complete packet (e.g. Twitter OG tags overrides)
    • How does Atlantis know what URL to include?
      • Atlantis should first save & need to check that if the URL is available in the CDN
      • Currently, Toolbelt UI takes time to reload – every caches are flushed out, so they haven’t encountered this problem
      • Atlantis would need to fetch after save / Atlantis would need to save some information from Toolbelt
  • Asynchronous vs. Synchronous
    • CNBC Team: Not too worried about too many # of users/requests, so CNBC would like to keep the option of synchronous open
  • Actual volume?
    • Share the # of times of saves, gets are called (Prasanth)
    • Probably hundreds of request per second, can get up to 5 times more
  • Where does an article get created?
    • Solely use Atlantis for creation
  • Once the article is saved in Toolbelt, can it be edited?
    • Yes, a revision would be made in Atlantis and messaged back to Toolbelt
    • Currently Atlantis would serve as the front-end
    • Ultimately completely decommission Toolbelt backend
  • Ingest from 3rd party (e.g. Wire Story)
    • Toolbelt has the ingest service in place
    • Editorial users should be able to edit those in Atlantis
  • Points of an entry as a second user for the created article
    • Status Tracker
    • Latest Published Content
    • Global Content Library < Revision service would be tracking the history of article creation
      • Everything in Toolbelt should be available in Atlantis – Atlantis as UI
      • Users can see: active articles & published articles
  • Is there a specific permission for editing an article?
    • Anyone can join in to edit the article via Content Library
  • How long do we need to keep the revision history?
    • Once the changes are committed to Toolbelt, the revision history in Atlantis can be flushed out
    • How long are you saving the autosaves in memory?
      • 12 hours? 24 hours? If not much difference, go for 12 hours
Dashboard API
  • Atlantis’s data that aren’t coming from Toolbelt – how to make pairings between Atlantis and Toolbelt
  • Chartbeat: has to be node ID or URL
    • Node ID works
    • Get information on this from the web team (CNBC TECH TEAM)
  • Favorites & Tasks to live Atlantis permanently
    • Association – make sure that Favorite URL can exist outside of Atlantis
      • Should have the ability to seamlessly put Toolbelt contents (e.g. contemplate) as favorites
    • Should have the ability to add and remove favorites from Atlantis, as we won’t build new functionalities in Toolbelt due to future plan to decommission
  • Identify actions that can be done in both places – so that no flipping between the 2 different UI happens
  • Favorites
    • READ & WRITE & DELETE
    • Save new favorites in Atlantis – if there are deletes and changes, we need to save that to Toolbelt
    • Inline search / sort filters
    • WRITE
      • Reordering (MVP)
      • Add to folder, create a new folder (non-MVP)
    • DELETE
    • READ
      • View / search (MVP)
      • View folder (non-MVP)
  • Task (non-MVP)
    • READ: view
    • WRITE: reordering, checking completed
    • DELETE: remove
  • Content Revision: My Latest Activities, Status Tracker, Latest Published Content
    • Revisions will be created when there are hard saves
    • Service from the API Layer
    • Publishing, Saving, Unpublishing -> Done in Toolbelt
      • Data comes from Atlantis for collaborative saving
      • Retrieve unpublish action in Toolbelt – action is initiated from Atlantis
    • READ: content that has been edited that I contributed to
    • Consider the cards as UI for fields of Revision Table of the whole CMS
    • Needs to consider and work out Field Revision
    • Whether to display or not can come from Atlantis
    • My Latest Activities would start from day 1 of Atlantis
  • Status Tracker
    • Field revision should know the status changes
    • Grouped by content items
  • Roles & Permission
    • Hot Seat Users: Option to display homepage banner & send mobile notification for content publishing
    • Photo Desk Users: Ability to license photos
    • Contextual, role-based cards and fields
  • Latest Published Content
    • Going to Toolbelt / Content API
    • Follow-up on how Content API could possibly fit
ACTION ITEMS
  • Versioning: Find edge cases to discuss (DPIM & CNBC Tech Team)
  • Review how the Social Service (tweet from Toolbelt) is built and inform Atlantis team (CNBC Tech – Prasanth)
  • Share the # of times of saves, get calls with Atlantis Team (CNBC Tech – Prasanth)
  • Get information on Chartbeat node IDs from the web team and inform Atlantis team (CNBC Tech – Prasanth)
  • Content Revision – Consider and work out Field Revision (Thomas)
  • Share the role-based card views (Joheun)
S-2: Login; Dashboard; Article Creation; Media Library
Login
  • Need to think about security in API – do work up front
  • SSO Login
    • SAML – probably not supported in Drupal 6, but can customize
  • Two-factor authentication
    • VPN – only available through certain IP
      • Issue: user from different location & set of IPs, new people, constant maintenance issue
    • Without VPN, need encryption, especially for API
    • OPEN QUESTION
Saving the last visited point
  • Use case: User leaves a page by either logging out or closing the window. Once he comes back to the CMS and logs in, he is immediately placed on the page where he left off.
  • Need to have CRUD live in one place
  • We will save it in the new system – as long as there’s a way to store in Toolbelt, augment with an API call
Dashboard
  • Favorite
    • Toolbelt has Favorites feature
    • All Toolbelt needs is the API call to add, delete, and read favorites
  • My Task & My Latest Activities
    • Not necessary to change the data structure in Toolbelt
    • For My Latest Activities, need to display Save & Publish & Assign
  • Status Tracker
    • Any actions like save, publish, assign
    • New system still needs to build a way to flag the tracking
  • Latest Published Content
    • Status will come from both systems
  • Article Statistics & Site-wide Statistics
Article Creation
  • Revert
    • Reverting action will take you to the previously hard-saved or published version, not the autosaved versions
  • Fields that will be added
    • Ability to add more than 1 byline
    • Source field with ability to add more than 1 source
  • Contemplates / Presets
    • There will be public & private presets for contents
    • User can create multiple presets per content
  • Byline
    • Type-ahead will look through the User that exist in the system
    • Can enter free text
    • Need to identify a single owning user:
      • Breaking News’ should be autofilled with “CNBC.com Staff” for Hot Seats – based on both Role & Content Type
  • Headline
    • Remove shorter/shortest headline & descriptions if there is no use case (explore with CNBC Product team – See if the templates are using the shortest headline)
    • OG tags come from Link Headline
  • Description
    • Rename it to “Summary” – Like a story summary for Alexa
    • Is the summary of the story a good OG description?
      • The ability to edit OG description inside Atlantis and show how the shared content would look like per platform in a card addresses this
  • Text Editor
    • What would be the ingest format for Toolbelt coming from the new system?
      • Content News API
        • body content is object: metadescription of the html
        • media references are easier
      • Toolbelt is NOT using Content News API – CNBC Tech team has investigated the API and decided not to use it for that time
    • We will use current Toolbelt XML
    • We will use API format whenever possible
    • Toolbelt would like to standardize API format
    • We need to share formats for Story / Apiary markup (Thomas)
    • Toolbelt is already using media references
  • Simultaneous Editing (Block/Paragraph level)
    • Each block is treated like a separate field – user is taking the ownership of the block
    • There are no services in Toolbelt to save the changes in the blocks – changes in the block as the user leaves the block need to be saved in the Atlantis database
    • Simultaneous editing would be achieved by constant communication with the server through websocket
      • Lives in data store server -> drained to database
        • Need to work out how often this needs to happen (explore)
      • “Work-in-progress” lives in the app, and the hard-save action is storing the content in Drupal
      • Need to:
        • Check if the data are matching between the data store server and database
        • Once publishing is successful, need callback to Atlantis
  •  Association
    • We need new content classification
      • re-structure Franchise & Primary Assets & Related Assets (explore with CNBC Product Team)
      • We need to keep Primary vs. Related
    • Auto-tagging – Explore options
      • Calais API using a set of vocabularies
      • Natural Language Processing
  • Media
    • All media in the body will be propagated in the card
    • 1st image default as Promo, can set any one of the image as Promo
  • Assigning tasks (non-MVP)
    • Slack integration: When a user gets a task assigned, it notifies the user on both “My Task” on Dashboard and Slack
  • Team & Project
    • Default to your team, e.g. CNBC US Team
  • Templates, Configuration, Settings
    • We need to audit and just display the ones that are used and make sure that removing something isn’t impacting the downstream (explore with CNBC Product Team)
    • Permission-based
  • Roles & Permissions
    • Ideally should be in place with the SSO integration, but we will build incrementally as per workflow
    • Configuration page needs to be addressed
  • Preview
    • Preview exists in Toolbelt
    • We can’t do real-time update – the content needs to be saved or published in order to preview
Media Library
  • Search & Filter
    • We should limit to using Toolbelt Search API
    • User will be able to filter by licensed state in Atlantis
    • Image used recently can be filtered out by Last Used filter in Atlantis
      • Also, there will be flags for the images that were used within the last 24 hours, so that an editor can make a decision to use them or not
    • 3rd party source images that are both licensed and unlicensed will be initially imported. The licensed images will be stored in Toolbelt along with metadata. Metadata can be edited and saved by user.
  • Focal point comes from Toolbelt
    • Toolbelt’s behavior of the focal point is different from Atlantis’s, so there are some added features that need to happen.
  • Metadata & storage
    • CURRENT: Akamai for image storage, rest of the data in Toolbelt.
    • Toolbelt will continue to store image metadata
    • Metadata in prototype are comparable to Toolbelt
  • Image edit (transformation)
    • CURRENT: Image edit happens in local server & file gets FTPed over to Akamai after save
    • OPEN QUESTION: how to implement image edit
      • Canvas & export to Toolbelt?
      • Or build a new service?
  • Auto-tagging
    • Option: Computer Vision in MediaLab
    • Getty & AP & Reuters should have enough metadata for searchability
      • We need to research whether 3rd party sources are exposing searchable metadata
  • Licensing
    • CURRENT: No licensing information is stored in Toolbelt
    • Atlantis needs to provide licensing storage
ACTION ITEMS
  • Dashboard
    • Identify what data Toolbelt has and identify integration points (Thomas & Prasanth)
  • Article Creation
    • Headline
      • Remove shorter/shortest headline & descriptions if there is no use case (explore with CNBC Product team – Catherina & Freddy & Joheun – See if the templates are using the shortest headline)
    • Text Editor
      • Share formats for Story / Apiary markup with Toolbelt Team (Thomas)
    • Simultaneous Editing
      • Work out how often we need to drain the data store server to database (explore with Tech team – Thomas, Sergey & Prasanth)
    •  Association
      • Re-structure Franchise & Primary Assets & Related Assets (explore with CNBC Product Team – Catherina & Freddy & Joheun)
      • Explore options for Auto-tagging (Tech team – Thomas & Prasanth + Product Team – Catherina & Freddy & Joheun)
        • Calais API using a set of vocabularies
        • Natural Language Processing
    • Template, Configuration, Setting
      • Audit and only display the ones that are used & and make sure that removing something isn’t impacting the downstream (explore with CNBC Product Team – Catherina & Freddy & Joheun)
  • Media Library
    • Decide on how to implement image edit (Thomas & Sergey & Prasanth)
      • Canvas & export to Toolbelt?
      • Or build a new service?
    • Research whether 3rd party sources are exposing searchable metadata (Thomas & Sergey & Prasanth + Product Team – Catherina & Freddy & Joheun)
S-1: Dependencies; Area to build first; Article
Dependencies
    • Two factor: VPN / SSO
    • No guest login
    • Authentication/Authorization
    • Mukesh/SSO discussion – Federated corporate SSO
    • Roles and permissions

a

  • User creation – permissions checked against the CMS – permissions used to identify roles in dashboard/UI
  • Not necessarily field based UI access in the beginning
Area to build first

Area 1 – Dashboard

  • Pro
    • Does not exist
    • Read only calls
    • Less confusing for editorial team
  • Con
    • Perhaps less impactful then other solutions

Area 2 – Article Creation

  •  Pro
    • High Impact – editorial ask
    • Broad Impact – Touches most users
    • Reusable components for rest of solution – ability to tackle more complex integration (e.g. draft storage)
  • Con
    • Risk: security, write level concerns, more complex integration
    • Must eliminate all use cases of story creation in order to ensure sole coverage in new solution
    • Requires potentials changes to ToolBelt UI based on proposed contemplate changes

Area 3 – Image Search and Management

  • Pro
    • Contained workflow
    • Introduces third-party image integrations
    • Seamless experience to ToolBelt (enhanced/replaced)
    • Not a drastic training concern
    • More self-service to editors – broader appeal than exists today
  • Con
    • Cost controls: Need to include licensing/finance in workflow
    • Integration of search results from multiple sources and determining relevance could be challenging (difficult)
Article
  • Existing Workflows
    • Identify all the points of entry for story creation
    • Support contemplates
    • None UI article creation (out of scope for this effort)
  • Create API exist – Article Ingestion Exists
    • News Content API ingestion as an example
    • CRUD functions for all the assets types in system
    • How is inline media handled
    • How are wildcards handled
Action Items
  • SSO investigation
  • News Content API integration
  • Determine how users will move back between ToolBelt and Atlantis
  • Identify entry points for Article creation
  • Share MVP for dashboard (tasks lower, statistics higher) and data integration points
  • Multi-gen plan for retiring ToolBelt UI
  • How handle search?