|
Looking for interested persons, negotiable high figgies Location: Remote Languages: HTML5, TypeScript, Python 3 Frameworks: LitElement, FastAPI Description of role: I need very motivated and imaginative engineers to help develop a new CMS UI and rendering stack for “boutique” digital signage, and support custom workflows of clients. Bespoke components in HTML5 and WebGL at 8K, typically 100-200 screens per client. Existing stack is ancient and needs replacing, completely flexible in technology choices. A pretty significant backlog of work currently with one dedicated front end engineer. Generally a closed environment for rendering, which means Chrome 101+ minimum currently and ES10 x TypeScript. Expanding to controlling DMX lighting and audio environments. Automated testing very much preferred due to high visibility of failures. Link/Contact: PM and visit not so hot website at https://zignage.com MrMoo fucked around with this message at 15:13 on Apr 5, 2022 |
#
¿
Mar 9, 2022 07:04
|
|
|
|
| # ¿ May 11, 2024 22:31 |
|
|
Oops, three positions open now: one for new CMS, one for a non-linear editor, and one for the playback of dynamic content on the player. MrMoo fucked around with this message at 22:06 on Apr 24, 2022 |
|
#
¿
Apr 5, 2022 15:20
|
|
|
Updated long job ramble: I currently have about 6 positions open, and it all depends what people are comfortable with. We also have an external contractor team working on various activities to assist on a project-by-project basis, such as a front-end logging system by an Ex-Googler. On the dev side positions include: CMS, player, graphics renderer, non-linear editor, and bespoke projects of CMS workflows and graphics. Outside of that there are operations, on-site technicians, and content editor roles. CMS I have narrowly defined as the server-side UI, it is currently Django 1.6 based, split into two sides, with all the "business logic" running asynchronously in Celery. Player is the generic name for the device that connects to a monitor or LED panel array. It is currently deployed as Chromium or Chrome, and the next version is technically finished, now using Electron. The player was technically quite complex, and now very much simplified with unit testing everywhere. It runs on x86 and ARM, including Raspberry Pi. In the future we need to try porting again to commercial Smart TVs and other vendors, however most use very old software stacks that are highly inconvenient to work with (Chrome 30's vintage for example on some Samsung models). Graphics renderer is what drives all the motion graphics in JavaScript et al. Today this could probably be a simple wrapper around WebAnimations, which would also simplify the relationship with the non-linear editor sitting in the CMS UI. For certain video wall arrangements WebGPU and WebGL need better support, with the latter having good utility at MLB on a complex LED panel layout. Non-linear editor is basically a giant JavaScript component for defining the graphics, i.e. PowerPoint or Google Slides, but with a timeline editor that users of Adobe Premiere Pro or Adobe After Effects would be comfortable with using. Bespoke CMS workflow refers to a UI dedicated for a given client to implement their business process for a given set of digital signage and equipment. The implication here is that the CMS is too complicated and they just want something simple and focused on their particular use case. The challenge for the CMS developer is enabling these per client without custom builds. Finally the bespoke graphics refers to the creative content and flow for a given client site. This typically is some sort of data broker suite to aggregate and cache content, and then the motion graphics side to present that data. So for each of these I have a high level roadmap, whilst being completely open to suggestions. CMS: 4 is the current version. It has a high level of technical debt. It is highly unrealistic to address. However it has a known interface that is a stepping stone with the next major version. See attached screenshots for reference, they are not pretty nor intuitive, but also not really that complex. You can blame me for the [S] on the status page, I just added that as a quick convenience. CMS: 5 is the next version that completely replaces the Player to CMS protocol. This requires some changes to the UI due to new ontology and a defined device adoption process. CMS: 6 replaces the entire backend supporting components to resolve most of the outstanding ticket list items. A relatively major piece is moving to a DAM model, with integration with third party DAM vendors. CMS: 7 targets features that are only practical on the Internet and with cloud infrastructure. Those changes refer more to technical backend changes, the frontend has an independent roadmap. n+1: Replace each page, the CMS is not a single-page-application, with an implementation that is supported, secure, and resolves obvious UX flaws. n+2: Move to an entirely new UI. We have a UI toolkit and high level UX design from an expert that is a heavy user of digital signage, and after many interviews with clients. It is not set in stone, but a basis to work from. n+3: Implement a store model for components that can be dynamically added and removed to a deployed system. I am not a web developer, thus only concentrating here on the higher level detail. However, I have written my own CMS, ERM, and OMS systems that are still in production at a multinational company, so I am only a little bit clueless. The graphics renderer needs some tweaking to operate with CMS 5 as it will become a standalone component rather than confusingly integrated. It comes from pre ES6M days but at least uses some web-components to reduce the burden. n+1: Needs a rewrite to ES6M to cleanup abstractions and define clean interfaces. n+2: Needs a new scheduler that support the concept of media items that define their own running time. n+3: Support the concept of a playlist of media items that can have additional items scheduled at certain time periods. n+4: Dynamically alter the playlist due to external triggers, e.g. astronomical time, movie showing time, baseball game play time. Bespoke graphics is the bucket containing all the one-off work that potentially can be upgraded to the product suite in the future. Here are some examples, all these look like early videos with random defects still in: Multi-LED panel at MLB store NYC: https://www.youtube.com/watch?v=_bT7arDZq5M Single TV at MLB store NYC: https://www.youtube.com/watch?v=JmRjeHBf2kQ NBA lobby: https://www.youtube.com/watch?v=bEqvikFCFH4 Loading many stocks at NYSE: https://www.youtube.com/watch?v=TpIjjJmtYXI So, for a CMS developer the remotely near term goals are: (1) Start CMS 5 to enable clients at distant locations with significantly less maintenance demands. (2) Implement a custom CMS workflow for a new client. (3) Create a new reporting page that simply permits a user to enter a date range and export a large CSV file. (4) Move to a supported technology stack for the UI, i.e. no more Python 2, and many other old components. I am not a fan of coder challenges, although I guess basic HackerRank ones are not too terrible. My ask is, how would you plan out your time to achieve the four above goals? How can we enable you to complete these goals more effectively? Here are some screenshots of the CMS, see how many odd design choices you can spot!    
|
|
#
¿
Apr 24, 2022 22:14
|
|