Xway strikes me as a lot like drag and drop ‘Bootstrap builders’ (Blocs, Mobrise, Pingendo etc) but without the framework support behind it. Using these tools to build pages is very easy but the user has to rely on the framework (Bootstrap, Foundation etc) completely. Adding 5 columns in Bootstrap, for example, has until recently been a hack. Also if you don’t subscribe to the framework’s way of working then you’ll find yourself battling against these rules in your site (predefined breakpoints for example).
Xway, on the other hand, leaves ALL of the choices to the user and offers most of the finite control for defining how the page elements adapt when pages are scaled. This is both good and bad in that those options can become daunting to new users.
I think there is an opportunity in the middle ground.
I would suggest heading in a direction where users can either choose a framework to base their website on (Bootstrap, Foundation etc), choose to start with one of these and add their own custom overrides as they edit their way through the site or create and use their own CSS components. Rather than making users define these elements again and again (images with captions, block quotes, buttons etc) they could be used again and again.
All of this assumes Xway can read and render non-Xway generated CSS. Jeremy, is Xway’s design view still an interpretation of the final page code (as Freeway’s was)?
On 7 Nov 2019, at 10:55, Tim Plumb email@hidden wrote:
All of this assumes Xway can read and render non-Xway generated CSS. Jeremy, is Xway’s design view still an interpretation of the final page code (as Freeway’s was)?
I’m not sure what you mean by “interpretation of the final page code”. Certainly, Freeway’s design view is not an interpretation of HTML/CSS, but the exact opposite: Freeway outputs HTML/CSS that is constructed from its DTP model, and it is this DTP model that is displayed in its layout view.
Xway differs from Freeway in that its data model is based on HTML/CSS. But it is based on a subset of HTML/CSS: the subset that it currently supports. It can’t import or display arbitrary HTML/CSS beyond that subset.
We’re working to increase this subset, and it’s possible that a future version of Xway will be able to import HTML/CSS, but it will take us a while to get there.
On Thu, Nov 7, 2019 at 03:11 AM, Jeremy Hughes wrote:
I’m not sure what you mean by “interpretation of the final page code”. Certainly, Freeway’s design view is not an interpretation of HTML/CSS, but the exact opposite: Freeway outputs HTML/CSS that is constructed from its DTP model, and it is this DTP model that is displayed in its layout view.
I guess what I meant to say was ‘Is Xway’s design view a webkit or webkit hybrid?’. If you can throw any HTML or CSS at the application and have it render in the design view then we can do a lot more with the application in terms of using frameworks and other foreign code.
I guess what I meant to say was ‘Is Xway’s design view a webkit or webkit hybrid?’. If you can throw any HTML or CSS at the application and have it render in the design view then we can do a lot more with the application in terms of using frameworks and other foreign code.
It’s not a webkit view, but we take it as a compliment that you thought it might be
Xway uses Cocoa views (and subclasses of Cocoa views) to draw in the Layout view. If you look at how borders (for example) are drawn in different browsers, you can see that Xway’s borders are not exactly the same as Safari borders, or Firefox borders, or Chrome borders. Dotted borders are a good example. CSS doesn’t specify exactly how dotted borders should be drawn. In this case we compared different browsers and wrote code that reflected what we thought was the best implementation.
[To see how browsers differ, preview a box that has a fairly wide dotted border and uses different colours (or border widths) for each border edge.]
On Thu, Nov 7, 2019 at 04:10 AM, Jeremy Hughes wrote:
It’s not a webkit view, but we take it as a compliment that you thought it might be
I had hoped the design mode would be ‘web based’ in some way as one of the things that I felt held Freeway back against competitors that simply implemented a ‘web inspector’ type view was that however good the design view was it couldn’t really cope with code that it didn’t understand. In a browser view (webkit or otherwise) all of that interpretation and rendering of the page code is done internally and should be identical to browsers that use the same rendering engine. Freeway (and is sounds Xweb too) had to interpret that page code itself which meant keeping up with the moving market a bit of a struggle for a small company with limited resources.
The page view is good, don’t get me wrong, and I’m impressed by how it just feels like the final page but I wonder how we’ll be able to keep up when asked to render and edit embedded or extended items.
The Blocs app, just by way of comparison, appears to be a webkit rendering engine that essentially allows users to edit the page code and post processes all of the changes to the code when the site is published. It isn’t too dissimilar to a web inspector that tracks changes and then applies those changes on output.
Whether we use webkit in future is something that we can revisit if we want to. Xway is pretty modular internally.
Webkit had serious issues when we used it in Freeway (e.g. for the Preview option), and I didn’t want to get bogged down with it when I started working on Xway.
[Webkit is Apple’s API to the underlying web engine. It’s quite limited in what it can do. It’s possible that we could use the underlying web engine directly, but it’s not something we would consider doing right now.]
NB Xway (not “Xweb”) rhymes with Freeway (not “Freeweb”)
As an example of benefit of having a “Web based” view…
Tim’s demo “site” page has a good example of where a basic user would be mystified if set the peacock image to Max-width 100% and seeing 100% in Xway. But then the preview seeing a caption and its wrapper at a far smaller width restricting the image size.
But then again if having a HTML caption shouldn’t it be using…
Blah blah Blah...
I’m assuming this is work in progress?
–
David Owen
On 8 Nov 2019, at 10:01, Tim Plumb email@hidden wrote:
I had hoped the design mode would be ‘web based’ in some way as one of the things that I felt held Freeway back against competitors that simply implemented a ‘web inspector’ type view was that however good the design view was it couldn’t really cope with code that it didn’t understand.
But then again if having a HTML caption shouldn’t it be using…
Blah blah Blah...
I haven’t had time to look at Tim’s document yet, and maybe I’m misunderstanding your point, but you can create Figures and Figure Captions directly in Xway (select them from the Type popup in the Box Inspector).
I agree the image captions in that file aren’t perfect. You shouldn’t consider it an example or best practice but more of a playground that we can all poke about a bit and try and figure out the best ways to do things. If nothing else it provides a good starting point for discussions.
elements would be great to see in Xweb as they would do away with a lot of that styling and jQuery in that page.
I did think about keeping the peacock at max-width:50% (as is the default) but ended up adjusting this as well as the CSS styles for the caption wrapper to keep the image at half size. In retrospect I think you are right and I should have kept the design view inline with the output and adjusted the CSS to suit. I’ll update that when I text revise the template.
Strictly speaking, a multiplication symbol () is different from an “X” - but if you want some other ways to pronounce “X” there is also “Trans” as in Xfer and Xmit.
Does anyone have an XS phone?
Do you say “Ten-Ess” (official pronunciation) or “Excess” (common pronunciation)?
(I gave away my pronunciation by unthinkingly writing “an XS phone” instead of “a XS phone”)
) is different from an “X” - but if you want some other ways to pronounce “X” there is also “Trans” as in Xfer and Xmit.