alaa_wmde added a comment.
I finally got the time to pay attention to this task. I'm apparently too late
to the party, for which I deeply apologize, esp. to @Pablo-WMDE and
@Matthias_Geisler_WMDE who did ping me before in person to have a look, which I
failed to do //for reasons//
**tl;dr** Our goal is to not not create a delay for bridge hike on this
technical matter as well as maximize the outcome of the discussions started
here about sharing components in the future across hikes. So let's copy-paste
and modify the component for the hike for now, and in-parallel put this/new
task in Trailblazing-Exploration board to research and experiment with sharing
components across projects.
----
After reading all the comments, I will follow up on this from where
@Pablo-WMDE has left it, with much appreciated effort to collect feedback and
clarify the ambiguous with @Charlie_WMDE and @Hanna_Petruschat_WMDE. The
conclusions, as far as the appear to the reader, are:
1. "primaryprogressive" button component introduced in termbox was meant to
be(have) exactly the same as OOUI per UX requirement.
2. It easy to reason about making that button component a shared component,
where shared here can be as far as sharing one and only code base for that
component.
3. However, in bridge case, the button need to appear inside a dialog header,
in which the previously developed component in termbox has no account (nor had
the requirement) for the extra special styling (no-corners) as OOUI button has
when placed inside a dialog header.
From engineering side, options I can see are one of two:
1. **[cheapest for the moment, my recommendation]** do not share the
component yet. Either start from scratch, or copy-paste the component from
termbox into bridge and modify it in bridge as necessary. Even if that means
the only modifier addition for border-less version.
2. **[not that cheap initially, might be cheaper for future]** extract
termbox component into a shared one, and add the modifier for the border-less
in that version. That component now has its own stable interface for the
outside world, in which adding the border-less version is viewed as just
another feature to serve another user.
Option 2 seems to have much higher initial cost and decision making efforts
for the following reasons:
1. it seems there's yet no official/reliable place out there for sharing vue
components. This means we will have to figure out where to host these
components, how to build, test and release them for use by external users on
our own.
2. we are still not that confident of whether that shared component would
stand the test of time, in terms of its requirements and use-cases from UX
side. It appears to be the same at the moment, but it is still quite simple so
far. The risks here are:
- more requirements to be added in the future to serve different needs,
making the component over-complex
- other projects creating their own components as the simple component
cannot serve them enough, rendering this shared component redundant before it
has proven to be useful for multiple users
both risks mentioned in 2 are quite small .. though their impact on lost
effort due to high initial cost of setting up things for it can be big.
For bridge hike, option 1 is recommended for now as it:
- has low cost atm following the simplest "reusing" technique, a.k.a
copy-paste, of the existing component from termbox, and customizing it for its
needs in the simplest way possible
- postpones decisions such as: what that first shared component should do to
serve different needs, how to be designed to do so, and how to do it
technically (build/test/release), to a point in time when we are more confident
about investing the initial costs having bigger decision to back it up such as:
building a style-guide and conforming to it all future/past designs (which I
feel we might want to do it at some point, but needs a little more discussions
and alignment)
- avoids overloading bridge hike with dealing and figuring out such technical
matters, which sounds more appropriate to be addressed separately outside of
its scope, in a trailblazing dedicated to look into it
TASK DETAIL
https://phabricator.wikimedia.org/T230326
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Matthias_Geisler_WMDE, alaa_wmde
Cc: alaa_wmde, Hanna_Petruschat_WMDE, Lucas_Werkmeister_WMDE, Lydia_Pintscher,
Charlie_WMDE, Jakob_WMDE, Michael, Aklapper, Pablo-WMDE, Hook696, Daryl-TTMG,
RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, Meekrab2012,
joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo,
Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420,
Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls,
Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan,
_jensen, rosalieper, Wikidata-bugs, aude, Mbch331
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
