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

Mobile Sketch Preview Screen #1467

Merged
merged 30 commits into from
Jul 1, 2020

Conversation

ghalestrilo
Copy link
Collaborator

@ghalestrilo ghalestrilo commented Jun 19, 2020

Part of the Mobile UI project. This PR adds a (working!) Mobile Sketch Preview screen (/mobile/preview), which renders the canvas with the project files and resizes it to properly fit the mobile view.

How to test:

  1. Run the app locally with the MOBILE_ENABLED flag set to true (MOBILE_ENABLED=true npm start)
  • You should be able to access /mobile
  • You should be able to edit code
  • Clicking the play icon should run the sketch and you to the preview screen screen
  • You should be able to go back to the code screen, and repeat the process without errors
  • Clicking the exit icon should take you to the default editor
  1. Run the app without the flag enabled
  • It should work as usual
  • /mobile routes should not be accessible

I have verified that this pull request:

  • has no linting errors (npm run lint)
  • is from a uniquely-named feature branch and has been rebased on top of the latest master. (If I was asked to make more changes, I have made sure to rebase onto master then too)
  • is descriptively named and links to an issue number, i.e. Fixes #123

Copy link
Member

@andrewn andrewn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking really great!

I have some comments and questions about the code. If this has been addressed in your next PR (or will be) then feel free to say that. :-D

client/modules/IDE/components/PreviewFrame.jsx Outdated Show resolved Hide resolved
this.renderSketch();
}

if (shouldRenderSketch(this.props, prevProps)) this.renderSketch();
// small bug - if autorefresh is on, and the usr changes files
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a bug that still exists? Should this comment be removed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the commend holds, since I merely moved code around. The logic is pretty much the same

client/components/mobile/Header.jsx Outdated Show resolved Hide resolved
client/components/mobile/IconButton.jsx Show resolved Hide resolved
client/modules/IDE/components/PreviewFrame.jsx Outdated Show resolved Hide resolved
client/modules/IDE/pages/IDEViewMobile.jsx Outdated Show resolved Hide resolved
client/modules/Mobile/MobileSketchView.jsx Outdated Show resolved Hide resolved
client/modules/Mobile/MobileSketchView.jsx Outdated Show resolved Hide resolved
</IconLinkWrapper>
<div>
<h2>{projectName}</h2>
<h3><br /></h3>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose of this mark-up?

<h3><br /></h3>

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It just heightens the header by an h3 height, to keep the h2 tag aligned with the previous screen - couldn't think of a better way to do this...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might have to use CSS to add padding to the h2? And maybe set the previous screens header to a know height?

Using h3 is this way is not semantic especially as screen-readers allow the user to list and navigate via the headings in the page, which will be empty.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I'm fixing this on the next PR, and improving the <Header /> component as well

client/routes.jsx Outdated Show resolved Hide resolved
@andrewn
Copy link
Member

andrewn commented Jun 29, 2020

I ran it on my iPhone and it works great! But the preferences and play icons are a bit small compared the the exit icon. They're a bit hard to tap and also a different colour with no press colour change.

iphone

client/theme.js Outdated
@@ -88,6 +88,13 @@ export default {
Icon: {
default: grays.middleGray,
hover: grays.darker
},
Panel: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are same colours as the buttons, so we'll have a problem if someone later puts a Button on top of a Panel as they'll be the same.

Shall we take the colours from the console header component? Cassie made accessibility colour changes a a while back to ensure the contrast worked across all the themes.

So:

Panel.default.foreground should be the value of console-header-color
Panel.default.background should be the value of console-header-background-color
Panel.default.border should be the value of ide-border-color

The colours are here.

I know it's a bit of a pain to do this, but it'll really help with the move to styled-components and away from SCSS and helping to make the design more consistent.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, but these are the colors that Panels use on the mobile UI (on Headers and Footers at least), so I'm not sure what to do. I wonder if they even mean the same thing on both UIs.

I think I'll create a Panel: { mobile: {} } attribute and keep these colors there, so the default Panel colors can be set to those of the default UI. Do you think that makes sense?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If possible, it would be great to have the same set of colours work for mobile and the legacy UI. My feeling is branching the theme into Panel.mobile and Panel.notMobile creates more code for us to maintain.

Your right that maybe this isn't a reusable panel colour, so if it's not possible to find common colours, then my preference is that we name the variable something other than Panel.

@catarak, what do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I investigated this a bit, and It's an important decision that goes beyond the scope of the PR, so I'll create an issue and we can discuss it there!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, good idea.

So shall we call this MobilePanel or something for now and we can get this merged in?

Copy link
Member

@catarak catarak Jun 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @andrewn, that it would be helpful if possible to not have mobile specific colors.

@ghalestrilo and I talked this over and thought it would make sense to open a new issue/PR with respect to the panel and button color contrasts, see #1484.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I'll update this :)

const IconButton = props => (<ButtonWrapper
iconBefore={props.children}
kind={Button.kinds.inline}
{...{ ...props, children: null }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need to put children: null here? Isn't children null here if you just don't put anything in between <ButtonWrapper></ButtonWrapper>?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's null if I don't pass anything, but in this case I wanted to pass children into the iconBefore prop, and not into the body of the component.
I thought of a better solution, so I'll change this soon

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I introduced an icon prop, now it looks a lot cleaner

client/modules/IDE/components/PreviewFrame.jsx Outdated Show resolved Hide resolved
</IconLinkWrapper>
<div>
<IconButton to="/mobile" aria-label="Return to original editor">
<ExitIcon viewBox="0 0 16 16" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you using viewbox here to change the size of the icon? I would prefer if you explicitly set the width and height, and maybe this needs to be added to client/common/icons.jsx, which could be done in a separate PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove the viewbox prop for now, and find a way to resize the icon in a future PR, to minimize conflicts with the other branch

<IconButton to="/mobile" aria-label="Return to original editor">
<ExitIcon viewBox="0 0 16 16" />
</IconButton>
<div style={{ marginLeft: '1rem' }}>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if possible i would prefer to not have inline styles!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The next PR fixes this by improving the structure of the <Header /> component

@ghalestrilo ghalestrilo requested a review from catarak July 1, 2020 19:44
@catarak catarak merged commit ff658c7 into processing:develop Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants