Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to the about page #86

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions docs/site/pages/about.mdx
Original file line number Diff line number Diff line change
@@ -10,11 +10,11 @@ title: About
What is Player? Simply put, Player is a framework that enables users to natively render experiences across multiple platforms via a declarative content payload. At Intuit engineers use Player to accelerate the development of new experiences as Player allows them offload data/state management and fit seamlessly with other applications all with minimal configuration.

## Why Did We Build It?
Player is the second iteration of this kind of framework. The first iteration that was developed for internal use and worked well but had its limitations. With limited extensibility, limited platform support, and no type support the framework stated to rapidly show its age as we tried to move into newer spaces. It was then determined that we needed to take our learnings from the past few years and rearchitect it from the ground up. And that's how we got Player.
Player came about due to the particular nature of TurboTax. The TurboTax product has over 50,000 individual screens that a customer can experience. Originally these screens were built using a framework that encapsulated data, flow and layout, much like normal HTML pages would, and were the result of over a decades worth of work of engineers and tax specialists. Maintaining this product was very time consuming and expensive, but then we decided to go mobile. Very quickly we realized that simply re-skinning the web product would not work but also rebuilding the entire product for mobile web was going to be extremely time consuming and not scalable. Maintaining 50,000 screens on one platform was proving to be challenging, on multiple would be impossible.

## What Makes It Special?
The first of the big changes with Player was using TypeScript over vanilla JavaScript. By leveraging TypeScript's strong typing system, we not only made it easier and safer to work on Player, but we were also able to expose our internal types in an easily consumable format. This paves the way for external tooling to be developed around Player.
We needed to come up with a new framework that would allow our tax pros and content authors to define their experiences once, but have them automatically available across every supported device. We also wanted to future proof the framework as native moble apps for both Android and iOS platforms were targets for product launch and we were experimenting with voice platforms as well. This meant that to get a truly amazing experience on every platform we had to build a framework where expereinces are not defined by pixels on screen but customer outcomes and intents. Thus came about Player-UI.

Now the biggest feature of Player: Plugins. This is discussed more in the Architecture section but at a high level, almost every component of Player exposes entry points to extend its functionality to make it work for your use case. We have included a handful of plugins we've developed alongside player but if none of those do what you need, the blueprint is there to build your own.
## What Makes It Special?
Player-UI is the first framework that takes a declarative and semantic first approach to building user experiences. The benefit of this approach is that you only need to author your application content and workflow in once and it is automatically deployable to every device we support. At the moment we support responsive web, native iOS and JVM/Android.

Lastly, Player has iOS and JVM/Android clients. On these platforms you can create native experiences with minimal overhead and not just render a web view. Components can also be written in their native language allow someone with zero web dev experience to use Player.
You may be asking yourself what is a "declarative" approach to authoring experiences. Well unlike other UI frameworks where you define both reusable components and larger order pages and applications using the same paradigm of HTML, JavaScript and CSS, Player-UI separates the concerns of the visual patterns from the application and experience logic. Instead of using things like Select boxes and Radio buttons, in Player-UI you define semantic Assets and Views. I can define a Choice asset which can render as a dropdown on the web or a picker in iOS and a grid of buttons on Android. You can then define the composition of your view, the data you want to show, business logic and navigational patterns, all completely abstracted away from implementation details of each device. Your UX development becomes more of "Ask the user a question then thank them for their feedback" and less of "div -> div -> div....."