Settings and activity
10 results found
-
3,612 votesfeature-under-review · 378 comments · Adobe XD: Feature Requests (Read-Only) » 05 : Asset exporting · Admin →
An error occurred while saving the comment 
Paul Mackinnon
supported this idea
·
An error occurred while saving the comment Paul Mackinnon
commented
another option I just thought of would be to facilitate exporting appropriate data, e.g. as JSON.
The rational is that you have expended effort on design, but now you want to flexibly reuse the information such as position of elements etc. It might be for web, but could be for another platform such as iOS autolayout constraints, etc. That data could be very useful to the production line
So why not include a JS API in XD (extendscript) and include all useful data in the API. From there it would be possible for developers to produce plug-ins that target specific uses (ANdroid, iOS, Windows, Web, whatever comes up)
Then, the most requested features i.e. Web, could easily be included by Adobe, or open to third party developers to sell
So, actually a few of suggestions:
JS API (extendscript)
HTML, CSS export
XML export
JSON exportFull Website export (for convenience)
Essentially most of the exports would be easily facilitated via a comprehensive JS interface in the XD application - to be clear that is JS that runs in the native XD app, and would also facilitate import, and other customisation of the XD environment
(in contrast JS that is intended for the prototype is a different feature, and may be relevant to other feature request such as custom widgets etc)
An error occurred while saving the comment Paul Mackinnon
commented
option A : It would be handy to export an artboard as simple HTML layout with assets, and simple CSS. i.e. if just the static layout as HTML it should be easy to adapt into any web project from there.
(Another option is the working prototype as functioning with JS for controlling the transitions, etc. But that would not be easy to integrate with another web project)
So I would quite like the simple (option A) type of export.
-
16 votesPaul Mackinnon
supported this idea
·
An error occurred while saving the comment Paul Mackinnon
commented
OK, I have been working with students on advanced interaction design where we have used HTML, CSS, JS to achieve the desired results.
Now after this project, I see that many students are designers and will prefer UI tools (such as XD) which do not allow any backend connections.
This is a problem.
No tool so far easily meets this requirement.
The backend we are using is called Firebase and the Realtime database integrates easily with HTML projects. What that has enabled is a "remote control" function where a separate mobile App is the "behind the screen wizard". So we can emulate situations and sensory data which would be much more difficult if done for real. An example is proximity:
A user walks up to a kiosk - the kiosk detects the presence of a user and reacts accordingly.
Now to actually implement this in a prototype is too hard and slow. Instead we have another person with the remote control press a button - signalling via firebase that such an event occured etc. The Kiosk App then receives that signal in real time and and it creates the illusion of smart sensors which in fact we do not have
So the dilemma is that Firebase is an easy integration with HTML, but not all students are fluent enough in coding to do this. I managed to integrate with Adobe Animate, but there were some problems, which again would challenge the students unnecessarily.
A more appropriate solution would be a killer feature for XD which would allow for a backend such as Firebase to trigger events. Or even a consideration of an Adobe backend, or a bespoke mechanism for this type of experience prototyping
I think that since Animate is quite close in allowing the easy integration, it would be possible as well in XD, but aimed at less code- literate UX designers
The feature could also be integrated as part of other feature requests, and I have commented on such requests as widgets which use Javascript for example. All you need is the global import and customized global JS, as well as some JS controlling of screen widgets / microinteractions etc.
I know its a big ask, but unless we find a product with this feature, we will not be 100% behind any offering, and painful workarounds leave a bad feeling
I do think that the XD product is probably in a position to include such a facility via general JS integration as described, which also solves a lot of other problems, such as live data, or choosing a different backend, or multiple users interaction via messaging on their prototypes.
-
1,792 votesfeature-started · 39 comments · Adobe XD: Feature Requests (Read-Only) » 02 : Prototype mode · Admin →Paul Mackinnon
supported this idea
·
-
2,509 votes
We think you’re going to really, really dig the plugin integrations we’re making available later this year :)
Hoyle
Paul Mackinnon
supported this idea
·
-
385 votes
Hi, all-
“Convert to code” is fairly ambiguous, and I’m looking for more specifics as to what you’re hoping to get out of this. We already have a number of stories that go to specific technologies: HTML/CSS, XCode, Android Studio, etc. I’d like to close this one out in the interest of having more specific export paths.
-Elaine
An error occurred while saving the comment Paul Mackinnon
commented
I mentioned this in the feature request for HTML export...
You should provide a comprehensive extendscript API (like other Adobe Apps) but comprehensively so that developers can write some Javascript to export the data they require
So rather than field further info on what formats to export etc, just give the power to obtain the data and let third parties develop the most requested plug-ins
-
Global/Master artboard templates (pin objects across all artboards)
-
universal_header_footer.jpg 178 KB -
407e7718-8237-47d3-a651-05edca3ee414.png 15 KB -
Screen_Shot_2016-09-01_at_19.45.36.png 779 KB -
Screen_Shot_2016-07-22_at_4.17.55_PM.png 144 KB -
Screen_Shot_2016-07-01_at_9.02.32_AM.png 10 KB -
Screen_Shot_2016-07-01_at_9.02.26_AM.png 14 KB -
Screen_Shot_2016-07-01_at_9.02.02_AM.png 17 KB
2,872 votesfeature-under-review · 148 comments · Adobe XD: Feature Requests (Read-Only) » 02 : Prototype mode · Admin →An error occurred while saving the comment Paul Mackinnon
commented
Symbols in Illustrator are like master items. If you repeated a symbol on many pages, and later updated that symbol, the change would propagate everywhere.
Page Masters in InDesign - if you change the master page contents, all pages based on that master change accordingly. Theres dynamic data in the page numbers too !
I like the Master pages idea since you could have a number of Master Pages which represent similar pages in an App.
You are then adding extra content to the actual pages. If the actual page needs to make a change to the master content, you ned to right click -> break link to Master. It is now unique.
If you "unique" a page, maybe the new edits will be required to propagate to more pages down this experience line. Perhaps You can right-click and "Make new Master". So lets say the pasteboard is filled with pages, and some are "Masters". You need to indicate with a small icon which are Masters. You may or may not use the Master as an instance as may suit your workflow. Alternatively like in InDesign, the Master Pages could have a special area to access, and edit. However I prefer to edit in place. This is behavour in Trimble Sketchup with "Components" - change to one affects all. However, that is no good, as the initial Master is like up a hierarchy, and its clones are children that should not change the Master in the use case. So the UI/UX needs to be considered. I would go for my suggestion of Masters indicated as such, and children pages able to show their inheritance tree.Now considering the same concept applied to "Symbols" which would operate similarly but as objects on a page - this is exactly possible in AxureRP and known as "dynamic panels".
When I learned AxureRP recently I realised that for a dynamic experience, the best way is to make every page a dynamic panel. And so that covers both cases - dynamic pages, and dynamic widgets.Paul Mackinnon
supported this idea
·
-
-
45 votesPaul Mackinnon
shared this idea
·
-
426 votes
An error occurred while saving the comment Paul Mackinnon
commented
Should have various standard user input elements such as textfields multi-line), textbox (single line), various types of multi-select, checkbox, switch, date-picker etc. These might vary by UI kit for platform - iOS, Android, Web. Would allow customised widgets to same effect.
When in prototype mode, clicking on a textfield would bring up the appropriate screen keyboard (on mobile simulation) or the actual platform keyboard where tested on device
Since these input widgets can vary by platform, maybe a plug-in or libraries means to add new sets - or to allow customised widgets to be made and shared either with your team or open source to everyone in community.
The simulation might allow selection of platform, or even some custom settings for example you get custom keyboards on devices by iOS extensions, etc. So the plug-in might allow a keyboard filled with emoticons for example, and it would be testable in simulation, as well as on devicePaul Mackinnon
supported this idea
·
-
1,962 votesPaul Mackinnon
supported this idea
·
-
1,151 votesfeature-under-review · 32 comments · Adobe XD: Feature Requests (Read-Only) » 02 : Prototype mode · Admin →
An error occurred while saving the comment Paul Mackinnon
commented
There are two big features requested here. These should be 2 separate feature requests in order to get more votes:
1. Interactive text fields - text and form elements with keyboard for user input (iOS keyboard / Android keyboard) as required
2. Analytic service - recording user interactions with screen, voice, touches, and a web dashboard to perform UX analytics
Paul Mackinnon
supported this idea
·
Here's a better idea...
Take Muse. Say, this is not a tool for production web sites. It is a tool for web prototyping with responsive ability and modern HTML. Simplify it to just producing nice standard HTML for export. No need for fancy javascript widgets etc, let the developers do that. Just make Muse a great tool for web prototyping. Then give it a new name if you wish..
You know it makes sense