I've continued my journey with Singularity, and I'm enjoying experimenting with this framework. I've created an experimental site at Sassmonster.com (Github repository here at https://github.com/58bits/sassmonster).
I was discussing this framework, along with other 'semantic' frameworks (if that's the right term in this case) vs presentational markup frameworks like Foundation, and Bootstrap.
I was wondering if anyone could summarize the relative merits of the approach that Singularity (and the original Semantic Grid) takes - without requiring grid classes or attributes to be present in markup.
The main advantage, if I've understood this correctly, is the ability to dynamically change layouts independent of document source order or any fixed class attributes (e.g. new grid layouts and grid span settings at given breakpoints, including source order independent changes like a sidebar switching from the left to right sides).
I'm sure there are others but would be grateful for a summary from someone with more experience than I have ;-)
Lastly - in terms of the future of grid systems in general - will the general adoption of the CSS Grid Layout Module obsolete frameworks like Singularity?
The advantage to semantic frameworks is that they take abstraction a level deeper than class names. This gives you, the author, the flexibility to generate your own list of classes like Bootstrap or Foundation OR you can apply grid styles to any element without being restricted by classes. Classes are flat and inflexible but having logic abstracted to mixins provides significantly more flexibility.
The advantages you address have more to do with the output model. Singularitys default output mode is called isolation and you can read about how it works here: http://www.palantir.net/blog/responsive-design-s-dirty-little-secret. With singularity you can use old fashioned floats or even write modules for CSS grid layout if you want. Singularity was designed to be future-proof and provide a common framework to do many different things with grids.
Lastly, yes, grid layout does some really awesome stuff and I hope it makes Singularity and other grid systems obsolete. However the syntax and conventions of grid layout is not so great and you may want to abstract some of it out. Some of the conventions are similar to that of Singularity like ratio based column math so that is pretty cool.
Related
I'm allowing users to select an icon from the full list of FontAwesome icons (using a List<ImageVector>). I'm going to open a dialog, and show the icons as IconButtons arranged in the list. There are ~1600 icons.
I implemented it using a LazyVerticalGrid, with a fixed number of columns. It works, but there's some lag loading the icons, and lag when scrolling the icons.
I'm converting this from a React Native project where I did the same thing (with a larger set of icons, actually) and scrolling that was pretty snappy, so I'm assuming it's possible to do performantly on native. Perhaps ImageVectors are heavier than the SVGs I was using in React Native?
I'm planning to provide a search box in the dialog where users can filter the list down by doing a fuzzy search on icon names, so the grid will change over time.
What sort of patterns should I be looking at here? Is LazyVerticalGrid the way to go, or should I be using a different approach entirely?
On Laziness
For an overview of use cases and appliable patterns you might be interested in the Android Dev Docs' page on Lists and Grids, încluding the topics Large data-sets (Paging) and the Tips on using Lazy layout.
This might wake your interest on the Android Jetpack Paging Library androidx.paging, which is designed for loading and displaying pages from large datasets, basically uniting the concepts of Laziness and Caching.
Currently you're only using Laziness. As Bartek Lipinski commented, that should usually be fine when the graphics to display are static. However, when they have to be loaded asynchronously, Paging will probably improve your performance.
Some Rules of Thumb
Scrolling
Pattern
No
Column or Row will be enough
Some
Column or Row with modifiers verticalScroll and horizontalScroll
More, static content
LazyColumn or LazyRow, resp. for gridding LazyVerticalGrid or LazyHorizontalGrid
More to mass, dynamic content
LazyColumn or one of its relatives with LazyPagingItems, so using the Paging Library androidx.paging
Also, as the docs say, consider adding contentType
. However, as Bartek Lipinski remarked, one usually benefits of contentType when there are scrollable elements of various types -- not only SVGs as maybe in your case. Still, giving hints to the system doesn't hurt, at least.
On Vector Graphics
As discussed in the comments, esp. by Subfly and Bartek Lipinski, though Laziness should be the main thing here, another bottleneck could be the loading of vector graphics during runtime.
If the graphics used are of static nature, then consider the usage of vector graphic assets. Those are supported for SVG and PSD since Android 5.0 (API level 21). Take also a look on the recommendations and some aspects of support and restrictions on SVG.
Summary
The basic formula is Laziness + Vector Assets with focus on the first. One might spice that with contentType and Paging.
I wanted to know from someone with field experience, what the best practice of implementing a programm, with UI or CMD in multiple languages (letting the user choose e.g. between English, French, German) is.
If there already exists a discussion about this topic I would be grateful, if somebody could send me a link to it, the first few Google searches I only found things like how to choose a programming language
The first options that came to my mind where switch(globalStringLanguage) and #ifdef GERMAN #define PROGRESS Fortschritt... .
Would really like to know, if there is a best practice out there(and which one that would be) and how you guys implement it in your firm.
Thanks in advance for the replies,
1973ProgrammingDude
There are 4 'best practices / topics' that you can research:-
i18n - internationalisation
This is more about the way you design software. You design buttons etc. to 'lookup' the text they should contain from a dictionary file rather than hard coding them into your source code.
It also applies to things like dates and currency and allow them to be formatted differently depending on the language / locale.
If you design your product correctly you should be able to change all the text on buttons, links etc. and change the date format, currency formatting etc. with one language variable being changed.
Think of this part as designing your system to account for translation, local formatting and even right to left layouts for languages such as Arabic that are read from the right to the left
l10n - localisation
This is the process that follows on from designing your system under i18n. You would define formatting options so dates etc. are correct.
You would also define wording of buttons etc. so they are correct.
Finally you would also have a system so that content could be translated for the given locale.
Think of this part as the actual translation process.
l12y - Localisability
pretty much covers the process and considerations of l10n - just mentioned so you can research it for more complex scenarios and implementation ideas.
g11n - Globalisation
Encompasses all of the above standards, yet again just mentioned for reference as it occasionally throws up some different articles on Google when searching on how to solve a particular problem.
Quick sanity checks
When designing a system that supports glln it easier to have a couple of points to help make you think about decisions you are making.
If you enter ANY plain text within HTML tags / controls / whatever is applicable to your chosen programming language then you will likely have made a mistake. Every item of plain text should be programmatically inserted into a page.
Design a dictionary system - for every piece of plain text you want to add to the site add it to a dictionary. The dictionary can be a simple key:value list if you need with the key being the English translation and the Value being the translation for your locale. Make sure that you start with English:English translations so you can make sure you don't miss any. I would recommend JSON arrays as most translation companies will now understand how to use these nowadays without you needing to design a user interface for them.
When designing a widget / component consider implications of longer text - just because a layout works in English (i.e. a button group fits on one line) doesn't mean it will work in another. Some languages may be 3 times longer for the translation of a word so you must consider this when designing a layout.
Everything should be designed so it can easily be reversed. Right To Left versions of everything should be easy to implement so design your system so only a couple of variables need changing to create the RTL version. (i.e. if web based have a main CSS definition of a widget and then make sure a global CSS class applied to the body can switch the layout).
It isn't just text -> imagery needs to be different as different cultures will interpret an image differently. Also iconography should be internationalised as well as a dollar bill icon doesn't work well to represent money in the UK, never mind in other countries.
CSS Example but the principle applies to all languages / platforms
.widget{
//define general styles
}
.left-to-right .widget{
//add some formatting to adjust layout for left-to-right languages such as English when the 'left-to-right' global variable is set.
margin-left: 20px;
}
.right-to-left .widget{
//add some formatting to adjust layout for right-to-left languages such as Arabic when the 'right-to-left' global variable is set.
margin-right: 0px;
}
I've been working exclusively with ComponentArt controls and want to know what else is out there. What Grid and Treeview controls are worth investigating?
It doesn't matter if I need to pay for them... quality, speed, and reliability are key.
I've seen a few issues with the CA Grid Control has issues with setting the column width dynamically, and documentation is spotty. However it has a single programming model with the SOA offering. Are there better options out there?
Try dhtmlx Grid and dhtmlx TreeGrid , although these are javascript components we have used them with asp.net and find them to be very fast and flexible.
jqGrid is a nice AJAX-enabled grid written in JavaScript that has worked out well for me in several recent projects.
jQuery treeView looks like a bare-bones treeview that may be worth investigating, although I have not used it on any projects so your mileage may vary.
I use the Telerik's AJAX/Silverlight grids for my web apps and I am pretty content with them. The components are flexible and designed with the idea of rich set of features without compromising the overall performance. If you want to have a look at their online examples, go here.
Dick
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm a blind college student who is taking an introduction to programming class that focuses on user interface design. The class is using Processing, which is completely inaccessible. I'm looking for a language that will allow me to create GUI's without drag and drop and hopefully be smart enough to do most of the layout without forcing me to specify control positions in pixels.
I know Perl, Java, C/C++, c#, and HTML. I was considering creating HTA applications. My only requirements are that the language must run under MS Windows, and must not use SWING or GTK as the underlying toolkit.
I would say that xaml would be a good choice:
Pixel manipulation is not needed
Item functionality in code behind
Can add pixels changing for control
later on
There is a lot of documentation on
how to use it
Maybe if you give us an idea of what you will need the language for we can give you better suggestions.
Speaking as a blind programmer:
C# + WinForms: You can either create the code by hand and use layout managers or calculate the sizes in your head, or if you're using the JAWS screen reader then there are scripts which will help you in the WinForms designer.
C# + WPF: Here you define your UI in XML, but it is more complex to get your head around. Certainly look at this as it is a very nice solution. the other problem with WPF at the moment is that not all screen readers support this newer technology.
Jamal Mazrui at www.EmpowermentZone.com has created something called "Layout By Code", but I have no experience with this.
HTML+Javascript would be nice, but I doubt it'd be allowed in your course.
WXWidgets: I don't have a lot of experience with this cross-platform, multi-language UI toolkit, but I believe it has layout managers and is thus used by several blind programmers I know.
Finally, I used to design Win32 resource scripts by hand, calculating sizes in my head (no layout managers). This is certainly achievable if you wanted to take this route.
In summary, WPF's nice, but make sure your screen reader works with this kind of app. The next best alternative is probably WinForms. If you like Layout By Code then use it, but if this is a skill you want for employment, then keep that in mind.
take a look on XAML. I think it could be a good start for both modern Windows and Web UI creators.
Tcl/Tk will do exactly what you want. The pack and grid layout managers are based on logical relative placement of the widgets.
Although the "native" language of Tk is Tcl, many other languages have a Tk binding.
label .l -text "this is a label"
button .b -text 'quit' -command "exit"
pack .l .b
Check out this project on codeplex. It may help you (as an alternative to processing&java)
http://bling.codeplex.com/
ling is a C#-based library for easily programming images, animations, interactions, and visualizations on Microsoft's WPF/.NET. Bling is oriented towards design technologists, i.e., designers who sometimes program, to aid in the rapid prototyping of rich UI design ideas. Students, artists, researchers, and hobbyists will also find Bling useful as a tool for quickly expressing ideas or visualizations. Bling's APIs and constructs are optimized for the fast programming of throw away code as opposed to the careful programming of production code.
Bling as the following features that aid in the rapid prototyping of rich UIs:
* Declarative constraints that maintain dynamic relationships in the UI without the need for complex event handling. For example, button.Width = 100 - slider.Value causes button to shrink as the slider thumb is moved to the right, or grow as it is moved to the left. Constraints have many benefits: they allow rich custom layouts to be expressed with very little code, they are easy animate, and they support UIs with lots of dynamic behavior.
* Simplified animation with one line of code. For example, button.Left.Animate.Duration(500).To = label.Right will cause button to move to the right of label in 500 milliseconds.
* Pixel shader effects without the need to write HLSL code or boilerplate code! For example, canvas.CustomEffect = (input, uv) => new ColorBl(new Point3DBl(1,1,1) - input[uv].ScRGB, input[uv].ScA); defines and installs a pixel shader on a canvas that inverts the canvas's colors. Pixel shading in Bling takes advantage of your graphics card to create rich, pixel-level effects.
* Support for multi-pass bitmap effects such as diffuse lighting.
* An experimental UI physics engine for integrating physics into user interfaces! The physics supported by Bling is flexible, controllable, and easy to program.
* Support for 2.5D lighting.
* A rich library of geometry routines; e.g., finding where two lines intersect, the base of a triangle, the area of triangle, or a point on Bezier curve. These routines are compatible with all of Bling's features; e.g., they can be used in express constraints, pixel shaders, or physical constraints. Bling also provides a rich API for manipulating angles in both degrees and radians.
* And many smaller things; e.g., a frame-based background animation manager and slide presentation system.
* As a lightweight wrapper around WPF, Bling code is completely compatible with conventional WPF code written in C#, XAML, or other .NET languages.
Bling is an open source project created by Sean McDirmid and friends to aid in design rapid prototyping. We used Bling to enhance our productivity and would like to share it with other WPF UI design prototypers.
I'd probably try using C#. It has reasonably friendly interfaces to windows common controls and the like even without making use of Drag and Drop. Just don't make use of the designer and code as normal.
I don't program in Java but I know that Java provides for the programmatic creation of the UI AND provides some wonderful Layout Management components (Native to Java without requiring SWING). I first got exposed to Layout Managers back in the good-old-days of X11 with X Toolkits (anybody remember Motif, OpenLook, HP Open View?) and Java seems to have adopted similar technology.
You can create Windows, Dialogs and Menus all from simple layout managers.
Being sighted myself and not having worked too closely on anything that has ever been audited for accessibility or heavily accessed by blind users, I don't think my answer will be terribly thorough. My first instinct however is to say that some kind of dynamic web server architecture that generates HTML like C#, PHP or ColdFusion is going to fit your description of handling most of the layout for you without requiring that you specify control positions in pixels. There certainly is the availability to specify control positions in pixels via CSS, but it's not required. And I know HTML also has well defined standards for accessibility, whereas I'm not sure what the status is on accessibility standards with other kinds of software.
You could use javascript and html. There's a port of processing to javascript, so you know that it is powerful enough for the things that your class will cover. You can author html without knowing a single thing about what it looks like. In fact that is the preferred way to author html.
The main downside of javascript is not javascript itself, but the browser dom. That is the interface into controlling the html elements. However, a library like jquery, or mootools, or dojo can take care of most of those problems.
As for accessiblity, have a look at WAI ARIA also opera's intro to WAI ARIA.a
WAI ARIA is a way to build rich javascript applications while playing nice with screen readers. It's very cool. I've not seen more work and passion put into making the web stack accessible in any other programming stack.
Is there some standard way to make my applications skinnable?
By "skinnable" I mean the ability of the application to support multiple skins.
I am not targeting any particular platform here. Just want to know if there are any general guidelines for making applications skinnable.
It looks like skinning web applications is relatively easy. What about desktop applications?
Skins are just Yet Another Level Of Abstraction (YALOA!).
If you read up on the MVC design pattern then you'll understand many of the principles needed.
The presentation layer (or skin) only has to do a few things:
Show the interface
When certain actions are taken (clicking, entering text in a box, etc) then it triggers actions
It has to receive notices from the model and controller when it needs to change
In a normal program this abstraction is done by having code which connects the text boxes to the methods and objects they are related to, and having code which changes the display based on the program commands.
If you want to add skinning you need to take that ability and make it so that can be done without compiling the code again.
Check out, for instance, XUL and see how it's done there. You'll find a lot of skinning projects use XML to describe the various 'faces' of the skin (it playing music, or organizing the library for an MP3 player skin), and then where each control is located and what data and methods it should be attached to in the program.
It can seem hard until you do it, then you realize it's just like any other level of abstraction you've dealt with before (from a program with gotos, to control structures, to functions, to structures, to classes and objects, to JIT compilers, etc).
The initial learning curve isn't trivial, but do a few projects and you'll find it's not hard.
-Adam
Keep all your styles in a separate CSS file(s)
Stay away from any inline styling
It really depends on how "skinnable" you want your apps to be. Letting the user configure colors and images is going to be a lot easier than letting them hide/remove components or even write their own components.
For most cases, you can probably get away with writing some kind of Resource Provider that serves up colors and images instead of hardcoding them in your source file. So, this:
Color backgroundColor = Color.BLUE;
Would become something like:
Color backgroundColor = ResourceManager.getColor("form.background");
Then, all you have to do is change the mappings in your ResourceManager class and all clients will be consistent. If you want to do this in real-time, changing any of the ResourceManager's mappings will probably send out an event to its clients and notify them that something has changed. Then the clients can redraw their components if they want to.
Implementation varies by platform, but here are a few general cross-platform considerations:
It is good to have an established overall layout into which visual elements can be "plugged." It's harder (but still possible) to support completely different general layouts through skinning.
Develop a well-documented naming convention for the assets (images, HTML fragments, etc.) that comprise a skin.
Design a clean way to "discover" existing skins and add new ones. For example: Winamp uses a ZIP file format to store all the images for its skins. All the skin files reside in a well-known folder off the application folder.
Be aware of scaling issues. Not everyone uses the same screen resolution.
Are you going to allow third-party skin development? This will affect your design.
Architecturally, the Model-View-Controller pattern lends itself to skinning.
These are just a few things to be aware of. Your implementation will vary between web and fat client, and by your feature requirements. HTH.
The basic principle is that used by CSS in web pages.
Rather than ever specifying the formatting (colour / font / layout[to some extent]) of your content, you simply describe what kind of content it is.
To give a web example, in the content for a blog page you might mark different sections as being an:
Title
Blog Entry
Archive Pane
etc.
The Entry might be made of severl subsections such as "heading", "body" and "timestamp".
Then, elsewhere you have a stylesheet which specifies all the properties of each kind of element, size, alignment, colour, background, font etc. When rendering the page or srawing / initialising the componatns in your UI you always consult the current stylesheet to look up these properties.
Then, skinning, and indeed editing your design, becomes MUCH easier. You simple create a different stylesheet and tweak the values to your heat's content.
Edit:
One key point to remember is the distinction between a general style (like classes in CSS) and a specific style (like ID's in CSS). You want to be able to uniquely identify some items in your layout, such as the heading, as being a single identifiable item that you can apply a unique style to, whereas other items (such as an entry in a blog, or a field in a database view) will all want to have the same style.
It's different for each platform/technology.
For WPF, take a look at what Josh Smith calls structural skinning: http://www.codeproject.com/KB/WPF/podder2.aspx
This should be relatively easy, follow these steps:
Strip out all styling for your entire web application or website
Use css to change the way your app looks.
For more information visit css zen garden for ideas.
You shouldn't. Or at least you should ask yourself if it's really the right decision.
Skinning breaks the UI design guidelines. It "jars" the user because your skinned app operates and looks totally different from all the other apps their using. Things like command shortcut keys won't be consistent and they'll lose productivity. It will be less handicapped accessible because screen readers will have a harder time understanding it.
There are a ton of reasons NOT to skin. If you just want to make your application visually distinct, that's a poor reason in my opinion. You will make your app harder to use and less likely that people will ever go beyond the trial period.
Having said all that, there are some classes of apps where skinning is basically expected, such as media players and imersive full screen games. But if your app isn't in a class where skinning is largely mandated, I would seriously consider finding other ways to make your app better than your competition.
Depending on how deep you wish to dig, you can opt to use a 'formatting' framework (e.g. Java's PLAF, the web's CSS), or an entirely decoupled multiple tier architecture.
If you want to define a pluggable skin, you need to consider that from the very beginning. The presentation layer knows nothing about the business logic but it's API and vice versa.
It seems most of the people here refer to CSS, as if its the only skinning option.
Windows Media Player (and Winamp, AFAIR) use XML as well as images (if neccesary) to define a skin.
The XML references hooks, events, etc. and handles how things look and react. I'm not sure about how they handle the back end, but loading a given skin is really as simply as locating the appropriate XML file, loading the images then placing them where they need to go.
XML also gives you far more control over what you can do (i.e. create new components, change component sizes, etc.).
XML combined with CSS could give wonderful results for a skinning engine of a desktop or web application.