Change Details

## Context The Mobile Editing Experience (MEX) project aims to improve the experience of editing Items on a mobile device for existing and new Wikidata editors. ## Main Objective In Milestone 1, the team will translate the existing UX prototype into a working proof of concept ## Considerations - We do not want to maintain two UIs indefinitely, so we will develop a responsive UI for item editing - Limited internet access / less powerful mobiles devices users are key stakeholders - We start with a config setting that is turned on in Patch Demo via a DNM Gerrit change (like in ScopedTypeaheadSearch) ## Open Questions - How will we handle statements with other entity types? Can / should they be separated (e.g. lexemes and items) - What is a expected full feature scope of non-JS experience? - How do we want to Test this: only via patchdemo, on beta, with feature flag on production and will this possibly change as the project continues?

## Context The Mobile Editing Experience (MEX) project aims to improve the experience of editing Items on a mobile device for existing and new Wikidata editors. ## Main Objective In Milestone 1, the team will translate the existing UX prototype into a working proof of concept ## Considerations - We do not want to maintain two UIs indefinitely, so we will develop a responsive UI for item editing - Limited internet access / less powerful mobiles devices users are key stakeholders - We start with a config setting that is turned on in Patch Demo via a DNM Gerrit change (like in T321543 ScopedTypeaheadSearch) ## Open Questions - How will we handle statements with other entity types? Can / should they be separated (e.g. lexemes and items) - What is a expected full feature scope of non-JS experience? - What is the minimum device to support: - For JS - For non-JS - How do we want to Test this: only via patchdemo, on beta, with feature flag on production and will this possibly change as the project continues? - Extend/refactor existing code or do we need a greenfield? - How will this relate to existing mobile UI (e.g. minerva) - What performance benchmarks do we aim for no JS/ non-JS users, if any (e.g. Time to Interactive, Speed Index, Session Time)

## Context The Mobile Editing Experience (MEX) project aims to improve the experience of editing Items on a mobile device for existing and new Wikidata editors. ## Main Objective In Milestone 1, the team will translate the existing UX prototype into a working proof of concept ## Considerations - We do not want to maintain two UIs indefinitely, so we will develop a responsive UI for item editing - Limited internet access / less powerful mobiles devices users are key stakeholders - We start with a config setting that is turned on in Patch Demo via a DNM Gerrit change (like in T321543 ScopedTypeaheadSearch) ## Open Questions - How will we handle statements with other entity types? Can / should they be separated (e.g. lexemes and items) - What is a expected full feature scope of non-JS experience? - What is the minimum device to support: - For JS - For non-JS - How do we want to Test this: only via patchdemo, on beta, with feature flag on production and will this possibly change as the project continues? - Extend/refactor existing code or do we need a greenfield? - How will this relate to existing mobile UI (e.g. minerva) - What performance benchmarks do we aim for no JS/ non-JS users, if any (e.g. Time to Interactive, Speed Index, Session Time)