I have to make an iPhone app for a company which has a web based system, and wants to go mobile. Its known in advance that the UI of the screen will change fairly often (adding new labels, buttons, etc). Also, many elements on the screen have an If(condition) then (visible) else (hidden) type situation. For instance, if(user.isMember) then (showLoginButton) else (showRegisterButton) All this is a fairly common scenario for companies who want to take their we-offering as a mobile-app.
The challenge now is how to write a flexible UI. If I go the standard UIView type approach and add labels, buttons etc, it becomes static in nature. Further, since a lot of elements (for instance, in the above example, loginButton, registerButton, retrievePasswordButton) are overlapping (since they should be on the exact location on the canvas), the Interface Builder looks cluttered.
One solution I can see is to use HTML content in UIWebView. Considering HTML browsers were defines with the concept for Forms in mind, it makes logical sense. There would be some overhead of doing search/replace for the values in the locally stored html file (call it template now), but guess the flexibility provided will be worthy of it.
I would like to invite pros/cons for this approach, and any other approaches that may have worked for you in the past for making flexible UIs.
There are at least two basic approches, among many.
The first, as you mentioned, is to use stored HTML5/CSS/Javascript for each form, and run them in embedded UIWebViews. But there is no need to do search/replace on the device. Instead of modifying a template, just download a entire new "web page" for any form that has to be changed or updated. Very flexible, if all the elements you require are efficiently "webifiable".
The second approach is to use a Data Driven UI (there's an Apple WWDC 2010 video on this technique). Basically, for every view and every UI element, instead of putting it in a nib or creating it from hard coded parameters, you read a r/w database for everything needed to create the element: size, position, title, color, value, what method(s) it calls, etc. To modify, you download updates to this database.
If you need an updatable "native" UI plus application logic, you could use a mix of the above two methods: a Data Driven UI engine with optional string parameters consisting of Javascript for any object to call for custom logic, calculation, state changes, etc.
Related
Does anyone know if I can integrate GrapeJS into my own website so clients could build their own websites using it? IF anyone has done this, how easy is it and are there downsides?
This question is pretty open ended, but I'll take a shot at it.
The short answer is yes, you can use Grapesjs to allow clients to make their own sites; however, the details matter.
Grapesjs by default doesn't know anything about your stack, website structure, metadata, etc. You will need to either supply plugins or implement those features yourself. I've worked on a project for a company that used Grapesjs to implement single page apps and I'll include just some of the tweaks we had to manage.
Hiding certain layers that only confuse average users.
Hiding pretty much all of the styling, and using traits to allow people to pick from some predefined styles.
Take the html, css on store and generate the final html page, and store it in our static serving folder on the server.
Implement a wrapping "App" component that has traits for the different metadata we want users to control (open graph metadata, title, etc)
and those are just the big things, I'm sure I am forgetting several small ones.
For your application, you'll also need to implement a custom trait for links / buttons that allows you to link from one "page" to another. As well as, a way to allow a user to pick which page to work on.
The long answer is Yes, but Grapesjs is only the starting point.
Yes you can.
However it is not straightforward.
If you want to build a Drag Drop Editor like GrapeJS Demo, here is the Source Code - https://github.com/artf/grapesjs-preset-webpage
You can see an implementation at https://codegres.org/dragdrop
Is there any way to load an angular component in isolation for design & testing purposes? I am attempting to redesign some components for a fairly complex angular app (it was started in angular2-rc and although it has been updated it's still following some bad design patterns - mostly due to work previously done by inexperienced devs on unreasonably tight deadlines, needless to say we are now developing this in-house). This makes it difficult to access certain nested components.
Currently my workflow for designing and testing a component is as follows:
Run the backend app (because of authentication checks etc. - the app is entirely private so needs a valid login to access anything)
Run the angular app (ng serve handles this and will obviously auto reload on change)
Log in to app
Navigate back to the relevant page (due to the login redirect taking me away from the page I was on)
Fill in the required data on the page to get to the point where my new component would show in a normal use case
Design/test/etc my new component, making any necessary changes
if (!done) { goto 2; } else { return; }
This seems excessive for designing a single component. There must be a better way to simply load my component directly for design and testing purposes. Ideally I would like my workflow to be something along the lines of:
Load the angular component directly instead of having to run the entire app (preferably with a way to mock any necessary inputs, services, etc)
Design and test component to ensure desired layout, style, functionality, ux, etc - making any changes as necessary
if (!done) { goto 1; } else { goto 4; }
Integrate component into app
Is what I'm looking for even possible? Surely I'm not the first person to run into this problem - UI frameworks are the first come to mind given how they provide a library of generic components to drop in wherever necessary.
Am I missing something? Or is the only way to do this just to create a simple mocked test app and drop the in-dev components there for quick and easy access?
Update
To clarify, I'm specifically trying to rapidly & iteratively design this component from a mostly visual/rendering perspective. I need to ensure cross-browser consistency, responsiveness at different screen resolutions, elements not overlapping incorrectly or rendering offscreen, colors/fonts/sizes/positions are appropriate in the context of the component (eg. <h3> is too big and looks out of place, lets try <h4> instead and see how that looks) etc. where the component has nested components which need to be displayed.
I tagged the question with html & css intentionally - not because those are the languages the component uses, but because those are the aspects of the component I am trying to test.
Thanks to those who have helpfully pasted a link to the docs (which, yes I have read) explaining how to unit test the component and briefly describing how to test certain rendering conditions based on the code (applied classes, attributes, styles etc). What I was unfortunately unable to find in there are tests such as:
expect(myComponent).toDisplayIdenticallyAcross(browser.Chrome, browser.Firefox, browser.Edge, browser.Safari);
expect(myLabel.color).toContrastWellWith(myComponent.backgroundColor);
expect(myNestedComponent).toRenderEntirelyOnScreenWithoutOverlapping(true);
That is to be expected as these are more subjective things which can really only be tested by looking at them and making minor tweaks as necessary. I'm simply trying to find a simpler way to do that without having to reload the entire app a minimum of three times just to see whether having my heading left, center or right aligned looks better.
I think it's hard to do unit testing on visual characteristics like you describe in your edit. I've never had to do that for a react app, generally you build a component and worry about what it looks like, and partially worry about it's layout, and it's parent also handles part of it's layout because the layout can vary on different pages but the component itself should still visually look the same. Also if you don't want to keep refreshing the page you can use chrome dev tools to update the css and see how it looks, then when you pick something you like, apply it to your actual code
Components are just classes. And they can be tested as such.
More
https://angular.io/guide/testing#component-test-basics
I'm currently evaluating the combination of jQuery Mobile and PhoneGap. For my application, I need a kind of "inner application" navigation model: A fixed header that contains elements to switch between various contexts and functions, and the entire region below that depends on whatever function is selected. An example: The user selects a customer and can then switch between different data and statistics views concerning that customer. Alternatively, the user can switch between different customers while keeping the same view. Each function / view might again be a rather complex construct of multiple pages with its own navigation.
I think I understand the basic ideas of jQuery Mobile by now, but I'm unsure how to implement this "the right way".
I could do this simply by coding the entire header with the navigation into every single page, but that feels like a really bad idea - lots of redundant code, lots of places to insert tiny mistakes that are very hard to find.
I could try to add all the UI elements for the different views to a single page, hide them and only display the ones that belong to the current function. This doesn't feel right either - I suspect that the DOM would be really large and I suspect that this might cause various (performance) issues.
I could try to create the contents of the page that depend on the function dynamically using jQuery DOM manipulation techniques. This sounds like a good idea, but the individual pages can be really complex, and I'm worried that generating lots of complex HTML code using JavaScript will lead to an unmaintainable blob of code.
I could try to combine the approaches - code the individual pages in the HTML file and then somehow "link" them into the appropriate place using DOM manipulation - but I've never done that and I'm unsure if and how I can get this working.
I could try to put the "detail" page into an iframe - would this work at all?
What is the best / canonical way of implementing this kind of application? Do you know of any tutorials or examples?
Just detach your header and then reattach it to your new page. For instance:
$footer = $("#myfooter");
$header = $("#myheader");
$footer.detach();
$footer.appendTo('#newpage');
$header.detach();
$header.prependTo('#newpage');
$.mobile.changePage('#newpage');
Detaching does not kill all of your button handlers / etc. You will need to keep track of what page you are on or look at location.hash to do different things depending on what page is being shown.
--Greg Frame
Thex Interactive
www.thexinteractive.com
The first way is the easiest way to do it. That's the way i did it too. Also this gives u the freedom to add a button specific to whats in the browsing area for that page.
The second approach will have loads of extra calls which you don't want.
The rest of the approaches are not worth the effort.
I work on a web application product which allows mnemonics (i.e. an underscore below the character 'C', to allow a keyboard combination and the key C to trigger the "Close" button).
Forms are created by different developers and they can each statically set mnemonics for buttons.
Forms can be nested, so it is not necessarily known at design time the exact mnemonics which will be required for one page.
There can be at most one mnemonic using any character on a page containing many forms.
And here's the kicker, the forms must be able to be localised into any language, meaning that the 'C' for close may not even appear in the... [insert language] word used for "Close".
The ideal solution would be some algorithm where developers didn't have to manually specify a mnemonic, instead they would be worked out at run-time, they would be localised, and they would be both convenient and consistent (I did say the ideal solution ;-D).
So I was wondering, are there any good strategies for achieving something anywhere near the ideal solution?
EDIT: To clarify,
I'm not talking about keyboard accelerators, such as Ctrl+S for save, which is hidden on a menu. The mnemonics are only used for actions which are presented on the screen, under button labels for example. Not hidden keyboard shortcuts that would change on localisation (there are none anyway, we run in a web browser, so the only accelerators are those which are part of whichever browser is being used).
The problem with attempting to choose the mnemonics at design time is that the people responsible for developing the UI are not aware of the localisation, as it could be done months later. Also, the problem of using nested and modular forms means that even without the localisation, there could still be conflict.
Some of the ideas I've batted around include having a global mnemonic registry which forms could use to apply for a certain mnemonic based on it's localised label, the registry would then calculate which was the best use of available characters. Somehow it would have to maintain the state of that - such that the same form does not appear with different mnemonic sets over the course of the application use, it could possibly even be done statically and persisted.
Surely if I was looking to do something like that it would fit a more general algorithm - I just have no idea which one! :-)
I tried to do something similar on a past project, and abandoned it. It was too complicated to get done in any reasonable amount of time.
One of the challenges is that some languages don't have a single displayable "letter" that maps to a single key on the keyboard. Another challenge, in English, was that usability standards required the mnemonic letters to be consistent with those in similar buttons/menus in other apps. This can be difficult if you are dynamically choosing the letters.
I don't know if it could be called "best practice," but consider what Microsoft Internet Explorer does in Japanese. Note the familiar F, E, V, A, and D mnemonics on the menu and the toolbar. I imagine that it follows the same convention, where appropriate, for buttons on forms and such.
(source: sidenet.ddo.jp)
(I snagged that screenshot from a google image search. If it goes stale, you can find other pictures of jp-localized IE pretty easily.)
This is really a design problem, not an algorithmic problem. It turns out that most applications don't localize keyboard accelerators, including most Microsoft ones, although there are some exceptions in certain markets. Not every keyboard shortcut is a mnemonic; really, only a few of the most common ones are.
I should note that this election not to localize accelerators is a rather recent trend; prior to 2000 or so, it was still quite common to localize shortcuts in some products (examples being ctrl-F for "Fett" instead of "bold" in German and Swedish products). But the pendulum has swung in the opposite direction, perhaps as a consequence of MUI and similar features.
A few localization tools will help you on this; I saw this feature as a bullet point on a product I've never used called Visual Localize. I'm not sure how useful automatic assignment is, as it's a fairly hard problem to automatically decide which character is the best mnemonic representation anyway, without domain knowledge of a particular product.
Generally, it only makes sense to localize the underlined mnemonic characters on dialogs, and maybe in menus. Most localization service firms are familiar with this process, and some have tools to detect duplicates in any build-time resources before handing back the localized resource package. You might actually want to invest in locating or building a tool that can do this duplicate check at runtime, and run the tool as part of acceptance criteria.
For regular menu items or keyboard command sequences, it can be more confusing than helpful, unless you have a fully baked keyboard to command mapping customization feature.
The problem I see with doing this is at runtime, is what happens when you deploy a version which has new forms, and changes Close from alt-c to ctrl-c. Or when you have two actions on two different pages but they are both close, you want to make sure close is always alt-c. Even worse would be if the algorithim was based on something non-deterministic and could change over time without a deploy.
It just seems like you might spend more time trying to build an algorithim for something that should be decided upon at design time.
Summary for the impatient:
What I want to know is what you want to have in a new gui language. About the short answers mentioning $your_favorite_one; I assume you mean that, such a language should look like $your_favorite_one. These are not helpful. Resist the temptation.
I'm thinking on the user friendliness of XML based languages such as XHTML (or HTML, although not XML they are very similar), XUL, MXML and others ("others" in this context means that, I am aware of the existence of other languages and their implementations alternative to their original ones, and the purpose of the mentioning only these languages by name is, to give an idea of what I am talking about and I don't feel like mentioning any others and also, I see no point in trying to make a comprehensive list anyway.). I have some opinions about what features should such a language have;
The language should be "human writable" such that, an average developer should be able to code a good amount without constantly referring which tags have which properties, what is allowed inside what. XHTML/HTML is the best one in this regard.
There should be good collection of controls built-in for common tasks. XHTML/HTML just sucks here.
It should be able to be styled with css-like language (with respect to functionality). It should be easy to separate concerns about the structure and eye-candy. Layout algorithm of this combined whole should be simple and intuitive. Why the hell float removes the element from the layout? Why there is not a layout:not-included or something similar instead?
I know that I don't even mention very important design considerations like interaction with rendering engine and other general purpose languages, data binding, strict XML compliance (ability to define new tags? without namespaces?) but these are the points that I would like to ask what you consider important for such a language?
There will always be a tradeoff between ability and simplicity.
Personally I'm happy with the features of WPF (which uses XAML) for MS development. I dont find its complexity to be a barrier to developement at all.
However if your going to target your toolkit/language to a demographic that requires a higher degree of simplicity, you could possibly get away with leveraging an existing framework and provide the end user with a DSL specific to their needs.
Writing a new framework for the dev community as a whole is a mammoth undertaking though, and I suspect you will find that due to the wide range of features required that you will have to deal with a large degree of complexity at some point. Best of luck.
Most recent XML GUI language (not only for GUI actually) is called XAML. It has all that candies: styles, layout definition, objects initialization, etc. But it's a pain to write more or less large XAML files. Auto-completion helps but the core problem - forest of angle brackets - is not solved. Another problem with advanced XML-based GUI langs - they try to serve to several purposes at once, but XML syntax is not suitable for all situations. For example XAML supports data-binding, but why the hell I should write it in attribute string? It's first class feature and should have proper support.
IMO all modern XML-based langs suck terribly. Language intended for humans must not force it's users to write tons of brackets or do deep tags nesting. It must be user friendly, not computer friendly. My dream it to have GUI language with Python-like syntax.
In conclusion I want to say:
Dear XML-based langs authors, please be humane, don't create another language based on XML. Read some good book on Domain Specific Languages and please, don't make me type < and > symbols ever again.
You should have specified whether you mean web or rich client, but either way take a look at XAML/WPF. If you're anti-MS, then look at Moonlight, the Mono implementation of SilverLight.
I would like it to be easy to connect to any database, perform queries that return a recordset, and be able to parse and iterate easily said recordset to display its data in graphic controls, for example pie-charts, bar-charts, timeline charts (stock options like), node graphs with animation effects, all this at run time.
Easy mouse events catching, to implement any action on rollovers, mouseins, mouseouts, clicks, drag and drops, clipboard management, etc. A good infinite zooming capability would be great too.
I don't want to set a "datasource" that establishes a fixed connection between some column in my SQL query and some displayable element at design time, I want to perform any query that I want and show elements tied to any query field, anytime, in run time. I don't want to be only able to bind a datasource and displayable elements at design time.
css style capability for everything. Or something as simple and easy.
resize and layout taken care of automatically. Easy access to local files, to parse, play, display. Easy classes for image management, supporting transparency, resizing, etc. Basic and advanced classes for drawing in the screen: lineTo, rectangle, circle, animations. Even 3D.
Embedded fonts functionality. I don't want to worry about "will the user have this font installed?" Also I don't want to worry about DPI or screen resolutions.
Basic widgets: treeviews, etc.
A good designer. I don't want to add widgets writing the code. I want to place them visually in the screen.
Also, it would be good if it could connect to dlls made in C++ or COM objects in general.