This is a complaint about the quality of the content served by soundcloud's embed API (iframe)
The main css file has 235 KB (160kb gzipped) where 92% is not used at all.
The main JS file has 450 KB (149kb gzipped), possibly following the above situation.
We developers spend much time optimizing bytes from our websites. Seeing this after hours of work makes us think that soundcloud just don't care about us and users.
The main css file has 235 KB (160kb gzipped) where 92% is not used at all.
I am not sure you counted all possible views that widget might have.
The main JS file has 450 KB (149kb gzipped), possibly following the above situation
While we are trying hard to keep the weight of the widget low, you should realize that HTML5 widget is a complicated single-page JavaScript application that has many features, including API hooks to control the widget, ability to resolve various URLs, a way to customise the widget, a way for widgets to communicate with each other and more
We developers spend much time optimizing bytes from our websites. Seeing this after hours of work makes us think that soundcloud just don't care about us and users.
If you feel very strong about this, I would suggest to build only the functionality you need from the widget on your own – SoundCloud provides public API, so building a player with similar UI that only does things you need is your best bet – you could use tools like http://zohararad.github.io/audio5js/ or even https://github.com/kilokeith/soundcloud-soundmanager-player etc. for playback.
Good luck!
Related
We've built an app through Flutter and realising that some of our user behaviour is best created for larger screens, where people are creating best on desktop. I've seen that the codebase is viable for transporting to a web experience. We want to avoid the desktop app and build for a browser.
Has anyone had experience with building for web browsers using Flutter?
What's been your experience? How good is the codebase for creating things such as:
Messengers
Posting and threads
Spaces, like Pinterest folders or Padlet like these - NewHope Crowdsource Space
This is the app on the store if that helps.
I'd greatly appreciate any feedback, thoughts or experiences you've had. I'm wondering whether to invest in Flutter for web browser or whether I need to go back to JS.
Thank you
We're exploring whether to develop the website through a different language and looking for people's experiences if they've attempted this.
The experience is not much different than mobile development, if you're used to it, really I recommend you usage this variant. Only one source code for all platforms.
In addition, the use of libraries is practically the same. The only thing that changes is that it compiles to HTML, CSS, and JavaScript.
I only recommend taking care of the adaptability to different screen sizes, using mediaQuery (height, width) and Expanded Widgets.
The rest stays the same, your HTTP requests (Dio is an excellent option). To work the logic layer also the BLoC design pattern helps a lot.
We're beginning development work on a newsreader app which pulls stories from a RESTful API in XML format. Each story contains:
Html formatted text with links to external web pages (around 1000 words per story)
1 inline advert banner (640x100)
1-10 inline images (640x320 each)
The newsreader will load 10 stories at a time when opened. It needs to be robust and performant (smooth scrolling etc).
We're considering whether to display the stories using the native UIWebView or Three20 open source library but am not sure which is the best choice. UIWebView seems to have more flexible text formatting but Three20 sounds more robust and less prone to memory leaks.
I'd appreciate any advice anyone might have from their experiences.
Thanks!
Well, the answer is: Oh, it depends.
The three20 framework offers a lot of things that you would have to do on your own - if you need these offers. If you like URL-based navigation, this might be a plus for going with three20. You mentioned flexible text formatting, which you can achieve with both approaches. three20 allows you to subclass their classes, apply styles, ...
My advice: take a deeper look in the documentation, ask yourself, if you need more than one feature that three20 offers and decide then which way to go. As with all third party frameworks, you'll have to put some effort in making things work.
I am designing a web app from scratch, which would be a fluid-based layout and the same HTML would render on different screens using the adaptive CSS.
I am going to use adaptive CSS (or responsive design) for this.
I was looking to use a framework like SCSS (http://sass-lang.com/) which would improve my code maintenance efforts. I'll have lots of CSS files (and probably some skin based as well)
Since I am using adaptive layout, I am going to use CSS Media Queries for desktop/tablet/mobile CSS. I could not get an idea how well the SCSS would integrate with media queries and overall speaking , how much flexibility will it offer to me.
Please let me know your suggestions if you have used SASS/SCSS and in general, any other suggestions.
SCSS is essentially an extension to CSS, and is useful (with mixins) to void repetition in your code. It also provides a way to group blocks of CSS in semantically meaningful ways and gives you variables to avoid repeating yourself.
If you are using a framework such as Rails, it is no-brainer.
There are also frameworks which focus on layout such as 960 (and its variants), and Blueprint which also adds code for thing like buttons.
The underlying philosophy behind many of these is DRY (don't repeat yourself). One bonus of using an established framework is that many of the browser issues have been ironed out, so you can be sure that it will work cross-browser.
It is true that perhaps the code is not quite a lean as rolling your own, but with careful editing and making sure you minify the result and send it gzipped, this is not a major issue except on the most high traffic sites.
Personally I have objected to using frameworks in the past because of the small amount of additional redundant code, but after 15 years of hacking around browser issues, I now think they are a Good Thing.
Larry Wall said in Programming Perl, "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."
Anything that allows more people to use CSS in a repeatable and reliable way, to build on work done by other, and to try out some of the leading edge features has got be a good thing.
Engineering a site with media queries is still a bit leading edge. There are compromises in each approach and you should read up as much as possible before choosing one. Adapt.js is a good alternative if you don't mind javascript.
You may want to look into the HTML5 Boilerplate. This has some useful defaults, and lots of documentation about the HTML and CSS defaults that have been chosen.
Good luck!
I have not used media queries together with SCSS, but I don't think they conflict with each other. I have used SCSS extensively in my current rails apps, and it helped me to reduce the amount of code, and get a better understanding when to use which styles.
The tricky part will be what to have fluid (changing depending on the medias viewport size), and how to avoid repetition.
Have a look at the nice site Responsive Design with CSS3 Media Queries, to get an idea which parts of your layout may be fluid.
Have a look at 320+Susy (GitHub repo here). It uses the Susy grid framework extension for Compass. All of these tools are based on Sass and make use of media queries.
I typically work on web apps that will only be used by a small group of well-controlled people, but now find that I'm writing something that has the potential to be used by a very large population. This means that the design and "look" will be very important to the success.
While I can certainly code up something functional, it ain't gonna look pretty, so I know that I'll need to get an outside designer to make things look good. Never having worked that way before I had a few questions about the mechanics of how this happens and how to try to make things easier.
We do Java, so when building a rich interface, we use GWT. I know that when working with designers, they typically provide images of what the interface should look like without any type of "useable" output. My question is how best to bridge that gap between a simple drawing of an interface to a fully functional realized one.
Any thoughts are appreciated.
Well, "it depends", as always.
Nowadays, I don't think you can work wit someone who simply provides PhotoShop mockups. At least not at your level. Mockups are simply too static, and translating those mockups to actual pages that actually work with different browsers properly is a skill set all its own.
So, you need someone beyond simply a designer, especially if you are planning any javascript wizardry, animations, or other dynamic elements that don't capture at all well on a static image.
What you really want is an "operational" mockup. Static HTML files that look and behave as best as can be done to what the UI designer wants to do, including transitions, work flow, etc. This artifact can be run through all of the stake holders as a live mockup, letting folks "Feel" the site.
Once you have these HTML files, you can then do your part of backfilling these pages with actual server side content. Obviously you can start early working on models and working with the designers so as to have services ready to support the site functionality, but you shouldn't be committing any real time in to actual pages for the site.
As for interacting with the designers, I talk more about that over here: How can I make my JSP project easier for a designer to work with
I worked on a project very much like this. We had "comps" which were pictures of what the interface would look like. We identified common objects and build modules. Then built pages (this was for a web app) from modules plus any elements that were unique to that "comp".
A couple things to keep in mind that will make life much easier: use the comps/drawings as more of a recommendation rather than set in stone design. Try to identify common pieces early on and reuse code.
Also, designers aren't user experience gods. They often have a good idea of how things should work, but if you are close to your product and have a lot of product knowledge, don't be afraid to tweak the design as you and your group see fit. One thing that designers typically lack is product knowledge. They know a lot about general user experience and how a site should work, but they often won't know the in's and out's of your use cases and products.
If you are working with GWT, you should look for designers who are expert in CSS. Apart from, may be, the main layout of the website, all the application components like form fields, dialogs, tabs and grids etc. will need to be styled using CSS.
If the designers are not experienced in working with GWT, share the GWT's documentation about styling with them. It's a good idea to read these yourself as well. Specifically explore the GWT's theme-ing system.
Also try to make use of UiBinder as much as possible. This would allow you to stay as close to traditional HTML based design while still enjoying the GWT high level object oriented interfaces (both widgets and DOM).
Optionally you might want to tell the designers that GWT image bundles will automatically do "CSS Sprites" so they don't need to worry about page load performance issues related to images.
This question has been asked in various guises. However. this is a slightly different take on things. By web application, I mean an ultra lightweight frontend - ideally an HTML page with form and regular buttons, with as little dependence on heavyweight JS libraries like jQuery as possible.
The goal is simple. I want to write a simple forms based application for use accross various mobile devices. I thought going the HTML route would be the simpler route (since browsers get around the whole cross platform issue) but even the browser approach seems problematic because of differing screen sizes on mobiles.
I have two questions:
For a simple form based application like I have in mind (possible 3-4 screens in total), I think the browser based approach gives more bang for my buck - am I missing a trick?
Are there any resources that someone can point me to for:
a useful reference for minimum (i.e. lowest common denominator) window size (I forget the technical term for the visible part of a page)
perhaps an example that will show a simple HTML page that will render correctly accross multiple devices?
The HTML5 mobile boilerplate will probably answer a lot of the questions about how to best get things to work across browsers:
http://html5boilerplate.com/mobile/
They have example markup and template implementations for things like browser/device specific CSS hacks, getting a custom launcher icon across different device styles, and implementing offline digest.
You really need to answer two questions before you pick a platform. First, what mobile devices and/or device capabilities are your lowest common denominator? There are lots of variable capabilities between most of those platforms -- screen size, input method, platform speed and mobile platform to name a few. Second, what is your connection requirement? Completely different issue building something targeting spotty or no connectivity versus a fully connected app.
Then you can start thinking about what tool(s) might get you there. In general, a very, very simple HTML site will look okish on most platforms you list. I wouldn't roll with HTML5 functionality because you've got serious limitations there. And HTML/web apps are kind of moot if you need things to work with limited connectivity.
iOS (webkit), Android (webkit) and BB OS6 (webkit-ish), are fairly easy to develop for.
Windows 7 should be, but who knows? They aren't promising HTML5 support until end of year.
BB OS5 browser sucks if you hope to be doing DOM manipulation or fancy JS event listeners. It's really buggy.
Nokia...it's a crap shoot. Granted, they have about one year left before they ditch their OS anyways.
Screen sizes are an issue, as is the fact you can change the orientation. But that can be gotten around with some careful planning.
HTML5/CSS/JS is definitely the way forward for making cross-platform apps as easy as possible...be it in the browser, or as a compiled app.