cal.com
cal.com copied to clipboard
2.0 Apps / App Store / Singe App {View}
As discussed with Bailey over DM I'd love to give a go at this. Looking at the branches it feels like it's the best to create a branch from feat/V2.0
and create a PR back to that branch? :)
@JeroenReumkens nice! correct, fork feat/V2.0 and then give yourself the cookie: calcom-v2-early-access=1
@JeroenReumkens and let me know if you've any design/implementation questions ๐
Thanks both!
@Jaibles I do have a few questions indeed ๐
- Looking at the design I'm assuming that the right part is sticky and the gallery scrolls on the left side, right?
- What do we do when there's not images for an app. Should we remove the grey gallery section and align the text column to the left?
- Currently in the MDX for an app there's a
<Slider>
component, with any other content on top or below it. Looking at the new design it looks like all of the content, except the images are shown on the right side underneath the buy button. So my plan is to remove the<Slider>
component from the MDX, but keep the items property in the meta section of the markdown (probably renaming to images makes more sense). Then all of the content placed in the MDX is rendered on the right, and the images on the left. Would that work for you? - Looking at other commits I also feel that the approach is to NOT break any of the old pages / layouts? Thus also duplicating / improving any changed components and move them into the
components/v2
directory?
@JeroenReumkens
- Yes, sticky. Also a problem we need solved here so perhaps you can align on how we do this @CarinaWolli .
- I'm working to make sure it doesn't arise that we have no image. It's definitely possible to at least have one image for an app so ultimately this will be a requirement for an app so no need to account for no image in implementation.
- Let's hold on removing altogether as we may want it for mobile? Will produce designs.
- @sean-brydon can you take this one?
@Jaibles
Thanks! As for 3, looking at the below screenshot my main point is this:
Currently in the red section we have the meta data having all the different images. Where as below that there's the content, including in yellow the <Slider>
component. In theory there can be additional text above the yellow section as well. So having this slider in the content, kind of means that we need to render this as one block. However, looking at the new design, you see that the images are pulled out of the content, since all the content except the images is rendered on the right side. So by removing the yellow part we have more control over where we want to render the images (we can control it in code), rather than dictate it in content, which in my opinion can't work anymore with the new design.
Let me know if this makes sense to you. We could always jump om a brief call to discuss ๐
![Screenshot 2022-08-25 at 07 15 55](https://user-images.githubusercontent.com/2969573/186580761-9d766e5e-6cc3-4c78-bb7f-7c248a4ebe2a.png)
WIP ๐ฅฐ Mainly waiting for Sean's answer before creating a draft PR, since I don't want to commit my changes in the app component immediately in the right directory (v2 or not). Besides that still needs some small tweaking and responsiveness.
Few new questions that came up:
- It seems that the new app shell isn't setup in a way that it aligns the title (or in this case the back button) with the logo. Looking at other v2 pages I see similar behaviour, so we ignore this for now?
- The text "browse apps" is a text that's use on multiple places. Do we change all of them to "App Store", or only here? And how do we approach the translations for these text changes?
Sorry for my noobish questions. I couldn't find any docs around these things. Just point me to them if there are ๐
![Screenshot 2022-08-25 at 08 48 26](https://user-images.githubusercontent.com/2969573/186594595-dd47c33d-4925-4945-819c-35cffcb49bef.png)
![Screenshot 2022-08-25 at 08 48 45](https://user-images.githubusercontent.com/2969573/186594633-5b69ce03-1720-469a-9139-7401cfff8c72.png)
@JeroenReumkens
- Yeah ignore this for now - its on my list of To-dos to fix. Unless you fancy fixing it too ๐
- I'd say only here - unless you can notice other places in the design have also changed
For V2 components/pages - yes we are only touching V2 so this should not effect anyway components/pages in V1.
Thanks @sean-brydon . So as one final double check โ we do duplicate quite a lot then, to prevent breaking of v1? Even only a very minor tweak is needed? Or is the idea even that eventually v2 has 100% of the components and pages, and everything not in v2 could be deleted?
@JeroenReumkens Exactly we're duplicating to not break V1. In the near future we will replace all of V1 with V2 work. We are doing it this way so we can test V2 In staging/prod (If you are a admin) to ensure have no major breaking changes.