|
So, I am a college student, and I have some web dev experience through internships, but I was looking to expand my skill base while making a project website. What would be a useful/marketable framework to develop a site that's primary purpose is to stream audio? Think something like Pandora.
|
#
?
Sep 18, 2016 20:51
|
|
|
|
| # ? May 10, 2024 17:19 |
|
|
https://bugs.chromium.org/p/chromium/issues/detail?id=605840#c22 CSS hyphens coming to Chrome  I feel like I've been subscribed to this thread (there was one before this current thread) for years.
|
|
#
?
Sep 19, 2016 16:17
|
|
|
TeenageArchipelago posted:So, I am a college student, and I have some web dev experience through internships, but I was looking to expand my skill base while making a project website. What would be a useful/marketable framework to develop a site that's primary purpose is to stream audio? Think something like Pandora. Not a hell of a lot. Media/transcoding servers are still kind of off in their own little world. I think Red5 is still free, but it requires Java and is a bitch and a half to get configured and running, and it doesn't play well with out of the box shared/virtual hosting environments. Also most of these solutions are A)java and B)kind of framework agnostic, meaning it doesn't matter if you Laravel (lol) or Cake or Symfony or Ruby or what have you feeding into them.
|
|
#
?
Sep 19, 2016 23:48
|
|
|
Scaramouche posted:... meaning it doesn't matter if you Laravel (lol) or Cake or Symfony or Ruby or what have you feeding into them. Curious of those PHP frameworks why Laravel got an (lol)?
|
|
#
?
Sep 20, 2016 02:52
|
|
|
I need to make a pretty basic site with just a few pages and figured it might be a good chance to play around with one of those static site generator things. The focus is on getting everything nice and minified and fast-loading, but I'm also poo poo at design so some kind of basic CSS grid and typography rules etc. would be nice. That might be asking too much. I've always wished there was some kind of CSS framework that gave you a bunch of nice-looking components like Bootstrap etc. do, but which also has a build process that strips out any unused components so that you don't end up with a 500kb CSS file. The only name I know is "Jekyll" - any alternatives? Also this is going off-topic but are there any standard methods for dealing with Google's PageSpeed "Eliminate render-blocking JavaScript and CSS in above-the-fold content" warning? Are there any static site generators that are clever enough to figure out which bits of CSS should be inlined so that the top of the page can load without any blocking?
|
|
#
?
Sep 20, 2016 12:39
|
|
|
fuf posted:I need to make a pretty basic site with just a few pages and figured it might be a good chance to play around with one of those static site generator things. Pelican is good. So is Nikola.
|
|
#
?
Sep 20, 2016 14:46
|
|
|
If you don't want to write your own framework, going into bootstrap.scss and commenting out all the components you don't need is a good idea.
|
|
#
?
Sep 20, 2016 15:13
|
|
|
Can't you use the bootstrap customizer and remove the things you don't want?
|
|
#
?
Sep 20, 2016 15:56
|
|
|
Scaramouche posted:Not a hell of a lot. Media/transcoding servers are still kind of off in their own little world. I think Red5 is still free, but it requires Java and is a bitch and a half to get configured and running, and it doesn't play well with out of the box shared/virtual hosting environments. Also most of these solutions are A)java and B)kind of framework agnostic, meaning it doesn't matter if you Laravel (lol) or Cake or Symfony or Ruby or what have you feeding into them. Cool, thanks for the recommendations!
|
|
#
?
Sep 20, 2016 16:09
|
|
|
chami posted:If you don't want to write your own framework, going into bootstrap.scss and commenting out all the components you don't need is a good idea. HardDisk posted:Can't you use the bootstrap customizer and remove the things you don't want? Oh, yeah, that would probably work. I haven't used boostrap for ages so in my head it's still this big bloated thing. Looking at pelican now.
|
|
#
?
Sep 20, 2016 16:28
|
|
|
I'm toying around redesigning my website. I was wondering if it is possible to have two sticky menus on a site? I did a really rough mockup of what the I was thinking it could look like. Basically, there is a top menu that would be fixed and then there is a second menu that scroll up to nest under the fixed menu.   Is this possible? Would there be any complications — especially when it comes to mobile? Also, is it possible to combine both menus into one (like a hamburger menu) when the site is viewed on mobile? (I'm not a web designer but I want to have a reasonable idea of what I can do before I start working with one.)
|
|
#
?
Sep 21, 2016 04:47
|
|
|
It's possible but yeah, it'll take a ton of space so the usual approach to those menus is to collapse them into some sort of hamburger or textual link, or reduce it to the top elements. Generally mobile and desktop are separate concerns even if under the hood they share the same DOM elements, design something ideal for either. Collapsing menus into hamburgers for mobile is a pretty common pattern, not always the best but it serves it's purpose. Also, I think it pays to avoid the lorem ispum linksum and actually try to fill the content of your design. It might turn out it makes no sense when you try to fill it, or you'll come up with something better. Maluco Marinero fucked around with this message at 05:26 on Sep 21, 2016 |
|
#
?
Sep 21, 2016 05:23
|
|
|
Wait, you're not actually designing your site for 800x600 are you?
|
|
#
?
Sep 21, 2016 12:09
|
|
|
The Dave posted:Wait, you're not actually designing your site for 800x600 are you? No, I just wanted to illustrate the general look/functionality of the menus.
|
|
#
?
Sep 21, 2016 12:31
|
|
|
This CSS quandary has been driving me kinda nuts: I have a container and two images of different dimensions. I want the two images to be side by side and have the same height (which can be smaller than the container height). Their widths need to be adjusted to maintain aspect ratio AND still fit within the container. Any ideas on how to do it?
|
|
#
?
Sep 21, 2016 12:43
|
|
|
Haha whew okay. Yeah technically possible but seems to be likely bad UX.
|
|
#
?
Sep 21, 2016 12:49
|
|
|
Bodhi Tea posted:This CSS quandary has been driving me kinda nuts: If you're not supporting really old browsers, you could use flexbox.
|
|
#
?
Sep 21, 2016 13:00
|
|
|
The Dave posted:Haha whew okay. Yeah technically possible but seems to be likely bad UX. Trying to figure out my site's menu structure is driving me crazy. I can't seem to find a good solution.
|
|
#
?
Sep 21, 2016 14:34
|
|
|
The Merkinman posted:If you're not supporting really old browsers, you could use flexbox. Agreed flexbox would work nicely. Also, Bodhi Tea, if you have height and width attributes set on the images you can use a combination of a specific value on height and 'auto' on width in CSS which will maintain the original aspect ratio. code:Omits-Bagels posted:Trying to figure out my site's menu structure is driving me crazy. I can't seem to find a good solution. Eliminate nav items. There are few sites in the world that need 12 pieces of nav visible 100% of the time.
|
|
#
?
Sep 21, 2016 14:40
|
|
|
kedo posted:Agreed flexbox would work nicely. Also, Bodhi Tea, if you have height and width attributes set on the images you can use a combination of a specific value on height and 'auto' on width in CSS which will maintain the original aspect ratio. Yup. That's why I said put content in them. Most bad ideas can't survive honest content entry, so wherever possible I try to wireframe with legit looking content.
|
|
#
?
Sep 21, 2016 14:45
|
|
|
quote:Eliminate nav items. There are few sites in the world that need 12 pieces of nav visible 100% of the time. I'm trying to imagine my site like a guide book with chapters. It's hard to combine all the "chapters" into just a few categories without burying information.
|
|
#
?
Sep 21, 2016 15:31
|
|
|
Omits-Bagels posted:I'm trying to imagine my site like a guide book with chapters. It's hard to combine all the "chapters" into just a few categories without burying information. Well, then think about it this way – chapters imply a specific order and hierarchy. Right now you don't really have much of either. Maybe rethink where/how your nav is displayed? Also agreed with Maluco Marinero, put some real content in there to see if your UI holds up in practice. e: Oh wait, you're the Savvy Backpacker guy. Yeah, I'd say definitely don't do this. You're going to overload people with information. Your existing left nav approach is better than this imo.
|
|
#
?
Sep 21, 2016 15:35
|
|
|
kedo posted:Well, then think about it this way – chapters imply a specific order and hierarchy. Right now you don't really have much of either. Maybe rethink where/how your nav is displayed? Yeah, I'm the annoying Savvy Backpacker guy. I've also gotten feedback that having the left nav wasn't good either. I don't know what to think anymore.
|
|
#
?
Sep 21, 2016 15:46
|
|
|
Omits-Bagels posted:Yeah, I'm the annoying Savvy Backpacker guy. I've also gotten feedback that having the left nav wasn't good either. I don't know what to think anymore. Let's look at your user stories, and we'll come up with a good UI for you!
|
|
#
?
Sep 21, 2016 16:16
|
|
|
Lumpy posted:Let's look at your user stories, and we'll come up with a good UI for you! I don't even know what a user story is.
|
|
#
?
Sep 21, 2016 16:19
|
|
|
Omits-Bagels posted:I don't even know what a user story is. And that is why your UI is not so good.... *zen* A user story is, well... a story written about somebody who is visiting your site. "Joe is a 20 year old kid who went to community college and is avoiding the real world so he wants to backpack around Europe for a year. He's broke, so he wants to do it cheap, and has no idea what he's doing. He found the site on google." What is Joe looking for? What information does he need? What is he likely to click on? Etc. What could your site do for him that it doesn't do? Create little stories of all the different people you think will visit and make use of the site. By figuring out what they are looking for and what they need, you figure out what your content / UI should be structured like. If "Joe" types are a big percentage of your users, then a big "Cheap backpacking across Europe: The complete guide!" banner / button that leads to a series of posts is perfect. Users generally: aren't sure what they want, don't read, and hate long lists. So your job is to figure out how to quickly steer them to content that will help them, and to do that you have to "know who they are" via user stories if your site is a content-heavy one (as yours is.) Lumpy fucked around with this message at 16:41 on Sep 21, 2016 |
|
#
?
Sep 21, 2016 16:38
|
|
|
kedo posted:What are your user's goals when they visit your site? I'd assume they don't include "exploring someone's website." Without knowing what those goals are, it's hard to know how to improve the UX. You can figure out these goals by examining your analytics, or better yet asking your users. Once you know them, you can make informed decisions about how to better structure a page. What I'm describing here is the simplest form a UX process can take: define the problem, define user goals (by reviewing analytics, conducting surveys, performing persona/user story exercises, etc.), define your goals, test different UX solutions that you think achieve both. So my answer is do some research before you start changing things.
|
|
#
?
Sep 21, 2016 16:45
|
|
|
Just to be as explicitly clear as possible: the reason why we're suggesting you take a step back is because you're making decisions about information architecture based on what you think is best. Is it best for your users? Are chapters with each chapter listed in the navigation really the best way for users to navigate and consume your content? It seems like you haven't considered this in any sort of formal, systematic manner, so there's no way to know if your new navigation scheme will help or harm the user experience on your site. All you can know is that it's different. If you have considered the user already and have definitely come to the conclusion that chapter nav is best, then you just need to figure out a good UI for it. Having 12 links in header navigation is probably not the best UI. kedo fucked around with this message at 17:00 on Sep 21, 2016 |
|
#
?
Sep 21, 2016 16:56
|
|
|
kedo posted:Just to be as explicitly clear as possible: the reason why we're suggesting you take a step back is because you're making decisions about information architecture based on what you think is best. Is it best for your users? Are chapters with each chapter listed in the navigation really the best way for users to navigate and consume your content? It seems like you haven't considered this in any sort of formal, systematic manner, so there's no way to know if your new navigation scheme will help or harm the user experience on your site. All you can know is that it's different. You all are helping a ton. Thanks! A majority of my viewers are twenty-somethings who have probably never traveled to Europe before or they've only done it as part of a family vacation. Much of my content is aimed at them — some information is valuable to more experienced travelers (I'm trying to expand this content) but a majority is aimed at newbies who are totally overwhelmed. That's why I'm basing my thinking off how I felt when I first planned my travels 10 years ago. Maybe this is a mistake, but I assume that many of my visitors would be in a similar headspace. My Thinking: I knew I wanted to travel, but the idea of planning a huge trip was overwhelming. I really didn't know where to go or what I wanted to see. I knew Europe had lots of public transportation but I didn't know how any of it worked. I had no idea how much the trip would cost. I wasn't sure about hostels and other accommodation options. I didn't know what to pack since I'd be carrying around all my stuff for a few weeks. And I wanted other tips and advice for saving money and overall advice for Also, part of it was that I didn't know what I didn't know — if that makes sense. I think a lot of my readers are in this same boat. They have the dream that they want to travel, but they don't know where to start because this isn't a trip to Disneyland where you just show up and have fun. That's why I tried to break travel planning into what I thought were logical sections and then have individual articles under each section — planning, packing, transportation, lodging, city guides, etc. My goals for the site are to get people to click around after they arrive from Google or social media. I thought if they come looking for information about choosing a backpack they would see the menu and want to check out information about packing, train travel, budgeting, etc. Or, they would come back to the site later to explore as they continue the planning process. And I want them to click a shitload of my affiliate links. Omits-Bagels fucked around with this message at 21:25 on Sep 21, 2016 |
|
#
?
Sep 21, 2016 19:53
|
|
|
edit: nvm
Paul MaudDib fucked around with this message at 21:09 on Sep 21, 2016 |
|
#
?
Sep 21, 2016 20:53
|
|
|
A good rule of thumb is that if the first time a user sees your front page they can't see something that's obviously the thing they want, or very very close to the thing they want, then the only thing they'll click is the back button. Your website shouldn't be front-loaded, its front should just be a reference of the things that people think they want displayed in a concise and clear manner. Think about the last time you were searching for something you were interested in, and you couldn't find it in the top 10 results on google because they seemed to have none of the stuff you were looking for. You'd click another few links in which you'd literally open the link, see if it seems like the thing you're looking for, then if it doesn't stand out, then click away within a minute. The navigation menu would get a brief glance, the page content would get a slightly longer glance, and you'd scan the viewport for phrases that stand out. e: And in case it wasn't obvious, "this is the website I would have wanted then" is basically impossible to actually design. Unless you manage to nail a whole lot of UI/UX stuff right off the bat, it's going to be "this is the website that would have offered everything I wanted then, but I would have browsed away within a few seconds because it wasn't obvious it offered everything I wanted". What you want to aim for is "this is the website I could tell at a glance that it contains the things I would have wanted then". Even that's fraught with tons of UI/UX stuff, but the intent is properly focused on bringing the user's attention to the things that are useful. Red Mike fucked around with this message at 22:39 on Sep 21, 2016 |
|
#
?
Sep 21, 2016 22:36
|
|
|
Running into some problems with javascript dates and timezones. Basically the client runs a report that takes a date(s) as a parameter that is month/year. The client picks these dates via a datepicker and we are sending the resulting date.getTime() across to our service which runs the report. The problem occurs when the client is in a different timezone than the server, if the client picks September 2016, then what is sent across is 01-Sep-2016 in millis for his timezone, and if the client is in EST and the server CST and then since the report that's being ran truncates the date for month, it ends up running for August instead of September. My initial thought was just to stop sending the ms timestamp and just send month and year across as parameters, but most of what I read has suggested using UTC timestamps like we are. We could also remove the truncation, but that would probably confuse the client when he runs reports for September, which give him September data but are labeled for August.
|
|
#
?
Sep 22, 2016 05:33
|
|
|
How do you mean UTC time stamps? Surely if you're sendin around ISO standard date time with timezone data (or Zulu time), then there should be no drift errors across the service. My ideal is to convert to UTC ISO as soon as possible from the UI widget layer. There should be no doubt about the timezone/exact time once the value enters your application business logic, otherwise you're just gonna get wrecked by a mistake in your conventions some where. The only place where this gets tricky is with calendars (what happens when you put things in your calendar whilst in the wrong Timezone, for instance), but pretty much everything else should be super aggressive about converting a value to UTC ISO as soon as possible.
|
|
#
?
Sep 22, 2016 05:51
|
|
|
argondamn posted:Running into some problems with javascript dates and timezones. Basically the client runs a report that takes a date(s) as a parameter that is month/year. The client picks these dates via a datepicker and we are sending the resulting date.getTime() across to our service which runs the report. The problem occurs when the client is in a different timezone than the server, if the client picks September 2016, then what is sent across is 01-Sep-2016 in millis for his timezone, and if the client is in EST and the server CST and then since the report that's being ran truncates the date for month, it ends up running for August instead of September. You could send the dates in ISO 8601 format, with UTC offset to preserve the user's time zone.
|
|
#
?
Sep 22, 2016 05:56
|
|
|
UTC Timestamp is probably not the right thing to call it. I'm talking about milliseconds since the epoch, which is what you get from new Date().getTime() in javascript. ex. client in EST timezone picks 01-SEP-2016 00:00:00 through the datepicker, ms since epoch is 1472702400000, which is sent to the server that comes up with the date 31-SEP-2016 23:00:00. This is the same time, but the problem is that we are then applying a month truncation to the date on the server and changing it all the way to 01-SEP-2016. It would be nice if we either had the datepicker using the same timezone as the server, or if we sent and took account of the client's timezone.
|
|
#
?
Sep 22, 2016 06:37
|
|
|
You should be converting the format from the widget BEFORE you send it to the server, and when it comes from the server you should convert to whatever format your UI needs. All JavaScript needs a degree of border control when it's sending JSON to & from the API, it should speak the same format the server is at that point.
|
|
#
?
Sep 22, 2016 07:00
|
|
|
Sedro posted:You could send the dates in ISO 8601 format, with UTC offset to preserve the user's time zone. This'n. The Date object in all major browsers support parse and format with ISO 8601. Not all the browsers support all the possible 8601 formats, so try to stick with these: 2001-02-03T04:05:06.789+10:00 2001-02-03T04:05:06.789Z The non-colon timezone format works in some browsers, but Safari doesn't like it. Browsers only seem to support 3-digit microtime resolution. code:The toISOString method won't persist the timezone, so it'll be Zulu "Z" instead of "+10:00". The time will be adjusted appropriately. If you work with PHP, use DateTime objects. Be aware that PHP is still insane. DateTime::ISO8601 ("c") and DateTime::ATOM both don't support ISO-8601 sufficiently, and either choke on the Z or on the microtime. Instead use this date format: Y-m-d\TH:i:s.uP code:As Maluco says, standardise your formats for transfer. ISO-8601 is [i]the[i] format for dates. Timezones are for user convenience, your storage should probably be timezone-less, but that's up to you how you want to handle that. If you're doing something like a calendar and need to coordinate across timezones, either make it obvious to the use what timezone they're scheduling in (hint: its whatever the PC is set to) or better yet tell them what the time will be for the other people.
|
|
#
?
Sep 22, 2016 14:11
|
|
|
Keep in mind if you're doing lots of datetime poo poo in JavaScript, you should make use of the moment js library. Honestly most languages should come with a big ol fat disclaimer of USE A loving LIBRARY for dates, times and timezones. Honestly the only lang where I've felt the base implementation was decent enough to standalone was Python's datetime library. JavaScript's in comparison is just a bucket of warts you should avoid as much as you can.
|
|
#
?
Sep 22, 2016 14:18
|
|
|
Yes use moment but keep in mind that moment objects are not immutable which is really weird for a date library.
|
|
#
?
Sep 22, 2016 14:36
|
|
|
|
| # ? May 10, 2024 17:19 |
|
|
Horn posted:Yes use moment but keep in mind that moment objects are not immutable which is really weird for a date library. I have to agree that was an odd choice, but I don't begrudge it as the core of its was written before it was cool to be immutable in JavaScript (thank god that happened). Are there any other decent datetime library competitors in Javascript?
|
|
#
?
Sep 22, 2016 14:48
|
|